Quote:
Originally posted by sco08y
Speed: with MySQL the only way to get proper transaction handling is through InnoDB tables. (And these have all kinds of restrictions on them.) In a real life database, one to which you would actually entrust your valuable data, all those supposed speed benefits go up in smoke.
The only way to be able to do live backups is with InnoDB. Again, if you're doing a business website, live backups is not optional.
|
Well, I have to disagree. I work for a company that processes in excess of $500 million annually and uses MySQL 3.23.5x (haven't upgraded all the servers to 4.0.x yet). We have never used transactions (found very little use for them actually). MySQL has never crashed on its own. We had 1 incident where the hard disk filled up due to other process logging and MySQL basically bombed.
As for live backups... we do it currently. A simplistic solution is to set up a Master and a Slave. Take the Slave down every now and then to move the data off site, start it back up and it gets all the data it missed from the master. If you do this once an hour, you lose an hour's worth of data at most.
Quote:
Originally posted by sco08y
MySQL doesn't have stored views or sub-SELECTs. It won't, according to the authors, until someone writes it for them or pays them to do it. What does that mean for you? You get to write lots of iterating loops which will bloat your code making it buggier and harder to update.
|
Sub-selects are in version 4.0.x. Views will be in 5.x. Full foreign key support will be in 5.x
These are all overhead in my opinion. In 5 years of coding/designing transaction processing systems with MySQL, I've had very little need for sub-selects or views. I think these are over-used.
Quote:
Originally posted by sco08y
Stored procedures: They have to be written in C++. That means that all that iterating you have to do (because there are no sub-SELECTs or stored views) is going to result in repeated round-trips. You can kiss network transparency goodbye.
|
You can write UDF's in C. I saw a version someone hacked together to be able to write them in Perl. Not sure if that ever got developed further though. Probably just proof of concept stuff, but it worked within the limits of Perl 5 (threading is poor but is required for MySQL UDFs).
As for repeated round trips. Version 4.1.x supports prepared statements within the C API (not sure if Perl's DBD::mysql, or PHP supports these calls yet) . It also supports the sending/returning of multiple queries/result sets at one time.
Quote:
Originally posted by sco08y
Anyway, as with any DBMS, there are plenty of minor issues and it carries all the baggage of SQL. These are the problems that prevent the use of MySQL in anything but quick and dirty hacks.
|
Like I said, I use it at work for some pretty major processing. We have sub-systems that take over 3 million transactions daily. One system in particular takes 61 questions per second every single day.
Still running good.