Slashdot Mirror
Why MySQL Grew So Fast
jpkunst writes "Andy Oram, who attended the MySQL Users Conference which was held April 16-18 in Orlando, Florida, attempts to explain MySQL's popularity in his weblog at oreillynet.com. (More weblogs about the 2004 MySQL Users Conference can be found at the The 2004 MySQL User's Conference & Expo Blog Collection.)"
3: MySQL SILENTLY ignores portions of the SQL spec and doesn't inform the applicaion that it doesn't do what the apps need it to.
MySQL still doesn't support triggers, and I like advantages of having support for varchars larger than 255 characters. Postgresql also supports the more standard method of an auto-number unique ID field of the sequence (and argueably more flexible). I _really_ like the flexibility of authentication that postgresql offers, though I haven't looked at MySQLs authentication as exensively.
MySQL has grown up a lot though. Given how primitive and featureless it used to be it's gotten much better where the differences between the two have become smaller.
AccountKiller
What doesn't MySql do well? For starters, it's much slower than Oracle, MS-Sql, and even Foxpro.
I've never used MS SQL Server or Foxpro. But having very recently developed a project on two DBMS tracks (Oracle and MySQL) I can tell you that identical queries on identical schemata with identical data are provably faster with MySQL than with Oracle.
It has no row locking, no transaction support,
This is no longer true.
minimal cross-platform compatibility
Huh? I've successfully migrated several complex databases, and the associated applications, between MySQL servers on Linux, Windows, BSD, and Mac OS X with no problem. And I mean no problem; in most of these cases, I haven't had to make a single change to the architecture, data, or application code. Everything just works.
If you want to criticize MySQL, there are plenty of legitimate grounds to do so. (E.g., the lack of support for views, which in my primary job as a MySQL DBA drives me nuts at least once a week.) Don't just make stuff up.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Before all of the MySQL zealots jump all over you, I should point out that MySQL does have transaction support (with the proper table type, and so long as it's built in, and you're using a current enough version, and you made sure to tag your tables with the right syntax to make sure they are of the right table type, etc), and does cross-platform well enough (better than PostgreSQL, as much as I love that engine). I don't know about row-level locking, but I'm sure it can't be far now.
The biggest problem with MySQL is inconsistencies in both the engine itself and the development community. For years, the MySQL community told developers, "You don't need [transactions | foreign keys | triggers | stored procedures | subselects | ...]! You can work around those limitations in your application code and be better off for it!" Only they then go and implement those features that developers "don't need". That would be fine, except that the implementation of the features often leaves something to be desired, and have too many quirks. For instance, I mentioned above that you can only get transactions and referential integrity if you're using the correct table type. However, that table type is not the default, and even if you do create your tables properly to take advantage of those features, MySQL doesn't fail if the table type is not supported, choosing instead to make your table an inferior type. Now you think you have transactional support and referential integrity because your database built just fine, but what you don't know is that your hosting provider didn't build that table type into their deployment of MySQL, and you really don't have those features at all. Good luck trying to figure out why your data is corrupted even though you had proper transactioning in your code.
MySQL has other problems as well. For example, if I want a column to be NOT NULL, I want any code that tries to insert a NULL into that column to fail. I don't want the engine to try to pick some default value for me. If I wanted a default, I would've added a default. That's why default constraints exist. By that same token, if I want a column to allow NULLs, I want to be able to put a NULL in the column. I don't want the current date/time instead of a NULL. If I define a column as auto-incrementing, I want to get an error if I try to insert something into that column. I don't want it to quietly succeed.
There's plenty more on that page, though most MySQL apologists will tell you either that the problem is fixed (which is fine, except that being fixed in the latest beta is far different from being fixed in the most widely-deployed versions from different hosting providers and such), or that it "will be in the next release". These are the same people that will tell you that stored procedures are unecessary, and anybody that thinks they are is stupid (or they'll tell you that the performance gains from being able to compile your SQL code is negligible, while completely ignoring all of the other benefits of stored procedures ... *COUGH*security*COUGH* ...). And so on. MySQL is fine for what it does, but it's not the end-all of SQL software. Far from it.
Interestingly, nowadays no one seems to remember that in '97-'98, there were basically three usable databases: Postgres95: sometimes difficult to compile and set up; mSql from Australia, which was popular, but was for non-commercial use only (thus they excluded themselves from many "markets"), and mysql, which at the time looked like a buggy clone of msql, but free to use.
Most of the people at that time usually heard about apache + msql, and then stormed over to apache + mysql. Me, I managed to get Postgres95 to work, and never longed for anything else :)
mSql, aka minisql tried to make a comeback lately, but I they botched their opportunity years ago with this "non-commercial use" stuff.
"Ten years from now, they could do it in a few seconds." -- The Racketeer of the Hellfire Club, 1993, Phrack 42