Slashdot Mirror
8 Reasons Not To Use MySQL (And 5 To Adopt It)
Esther Schindler writes "Database decisions are never easy, even — or maybe especially — when one choice is extremely popular. To highlight the advantages and disadvantages of the open-source MySQL DBMS, CIO.com asked two open-source experts to enumerate the reasons to choose MySQL and to pick something else. Tina Gasperson takes the 5 reasons to use MySQL side, and Brent Toderash discusses 8 reasons not to. Note that this isn't an 'open source vs proprietary databases' comparison; it's about MySQL's suitability in enterprise situations."
The audience for both articles are for IT (upper)mangers. Most of your argument above would be better off for the technical lead whose doing the report for his immediate manager (maybe technical) who'll then give a report to the CIO or even to a manger below him that would say:
MySQL (GOOD)
Oracle (GOOD but expensive)
Excel (BAD)
Not that those managers inherently stupid (hope not), it's just that their more concerned with the bigger picture and the resultant budget.
I prefer Flambe as apposed flamebait.
Due to tue relative low incidents of formally trained Oracle DBA's being mauled by Tigers, you could also infer that formal Oracle DBA training will also protect you from Tiger attacks. (To re-use & mash up that old cliche).
What a lame argument. Of course there may be some bias, but the fact is that: Oracle kicks every other RDBMS at pretty much everything: Stability, speed (optimizations up the wazoo), features, consistency.
To be able to manage these systems efficiently & keep a "Q9" system up & running, the formal training certainly does help but I would argue is not required as the documentation is pretty damn helpful unless you get one of those wonderful ORA-600 errors (is that the magic "WTF" Oracle error? I can't recall).
Sure - the woo of mega bux will entice many into Oracle DBA training but the weaker resources fall off quickly. You can't fake it when your production system is down.
IANAODBA
The article is in CIO magazine, none of the downsides you mention is of a concern for a CIO. A Product manager? Maybe, even then probably not.
The 5 reasons to use it are far more informative than the 8 stupid reasons not to use it.
It boils down to corporate culture.
if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.
It is painfully obvious from the article that this writer was or is a consultant. All of the reasons not to use MySQL are PHB reasons. Not one is based on actual abilities or inabilities of MySQL. He seems to be intent on agreeing with a position that he doesn't understand or didn't want to take. "...I'd be hard-pressed to tell a conservative IT manager making a platform decision for a mission-critical application based on this factor that he's doing the wrong thing." Yes, it does sound like he would be hard-pressed to tell any IT manager that the stupid decision he was making was the wrong thing.
The info at the end of the article says that he guides many projects based on MySQL, but it is hard to believe that he has ever used it. It sounds like all of his research was with PHB's or admins that have never really given MySQL a good try. A good admin knows both the pros and the cons of the software he uses, and hopefully, the good out weighs the bad. Many people that use or even swear by MySQL could give you some good reasons not to use it, under the right circumstances. Obviously, this guy could not find any. Either that, or he did his research in the wrong area.
I realize that this is the CIO magazine, and that some CIO's really are PHB's. However, Tina was able to write a good article on why a CIO should pick MySQL and give good reasons that were understandable to both technical people and PHB's. The only other conclusion I can come to was that Brent was trying to steer people towards MySQL and thought a badly written article against MySQL was the best way to do that.
Great civilizations have lived and died on false theories. Don't mess up mine with a few facts.
These two articles were some of the worst pieces of literature I've ever seen in my life. The GPL and BSD licenses are "too free"? "Ajax" is a programming language powered by MySQL? Etc., etc. Oh my God... what crap!
My other car is first.
The link I have there for the MySQL internals doc seems to be invalid... It has moved to here: http://forge.mysql.com/wiki/MySQL_Internals_Clien
Here is a quote: I don't think that's a valid use of copyright, but I'm not a lawyer. Can anyone explain to me how that's a valid use of the GPL?
MySQL comes prepared to support all the most popular Web 2.0-ish languages, such as Ruby, Ajax and, of course, PHP.
I've got the php_mysql.so library, but I can't seem to find the MySQL library in my Ajax installation... Oh wait, ajax isn't a programming language. I'm sorry little things like that really get under my skin (e.g calling the CPU "the hard drive", "I've got the Internet on my computer", calling excel spreadsheets databases). In case the author of the article didn't know, postgreSQL also comes prepared to support Ruby, and PHP.
I also didn't see where they listed phpmyadmin as a reason to use MySQL. Seems like they always use that as one of the reasons.
For the article writer a product's maturity solely depends on its age.... *thumbs down* I wanted an interesting read and got this?
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
Does MySQL still truncate data that doesn't fit? I recall similar lists of criticisms posted here and elsewhere about MySQL and one of the entries is that numbers 'too large' or strings 'too long' for a given column are just silently whacked down to size. I thought then and persist in thinking that this behavior is pretty damning.
Lurking at the bottom of the gravity well, getting old
Agreed. Another point to be made is that many enterprise applications use the database layer as a storage mechanism and either don't optimize for the database platform or don't take full advantage of optimization capabilities on individual platforms.
When it comes down to it, most enterprise apps would not see a significant performance shift in either direction based on platform and in those situations it is better to go with the database vendor with which your staff has the most experience. Enterprise applications rarely support MySQL or even Postgres except via slow ODBC connectivity.
For those applications that do maintain extraordinarily large data sets and see very high traffic levels there is still the factor of familiarity and experience to deal with. For a cost differential adding up to 100s of thousands of dollars in those scenarios it is unwise to not to at least take a look at open source platforms.
I could go into which platform I prefer in different scenarios but it's really not a very black and white thing. From a CIO perspective the best thing that you can do is to push software vendors to support open source DB platforms out of the box.
From my own experience one of the main problems is a misleading feature set. When you choose MySQL you then have to choose one of five or so ISAM packages for it to sit on. This is a problem since they all have difference features. Do you want the one that supports multi-user, the one that is fast or the one with transactioning. Personally I want all of those and can't get them. Then we had problems with a number of queries where we had the where clause specify fields in the primary index and the optimizer cleverly would always do a table scan. Asking MySQL support led to the answer that we should edit the source fix the optimizer and submit it back to the project. A bit beyond the scope of our little project. Seem that MySQL is good for web applications where a web server talks to it with one connection and each exchange is atomic, so multi-user and transactioning support isn't needed, so you can use the fast/light isam package.
My point was that its stupid to continue to be locked into one tech because you're "already using it." Or are you still browsing the internet using Chameleon on Compuserve with an old 286 and Windows 3.0?
That is great to hear. The only question I have is why on _earth_ the safe (and standards-compliant) mode isn't the default, with the weird MySQL-only accept-Feb-30-as-a-valid-date kind of behaviour enabled with a special option for those who really want it.
It's this kind of thing that makes me still suspicious of MySQL. I hope that for the next release - 6.0 or whatever it is - they can make a clean break with historical stupidity, and release a DBMS that gives safe, ANSI-compliant behaviour out of the box. However, there's nothing wrong with letting the sysadmin deliberately loosen some of the transactional constraints in cases where ultra high speed is important, although note that for all its supposed emphasis on speed over correctness, MySQL is slower than Postgres.
-- Ed Avis ed@membled.com
Ah, the digg DBA. Thus running a *damn bloody simple* news aggregation site, you're well position to comment on the relative strengths and weaknesses of complex RDMSs. Sure.
Also, I'm a rubber chicken. Squeak.
Its just as easy to install sqlite or postgresql. Sqlite is either to admin than the other two since its not a daemon, just a lib to read/write the files. Use sqlite for single user or small stuff. Use postgresql when you need a database server. Mysql just doesn't fit in at all.
It's a sad day when a comment implying Google and Yahoo search engines are "powered by" MySQL gets a +5 moderation; and then puts Digg in the same category. I thought it was +5 funny, not interesting.
Not sure what you mean by "faster". In my post, when I say fast, I mean the humble act of selecting data, which is 90% of the queries in I'd bet most traditional web applications. I care less about insert, updates, and deletes because those just don't happen as much.
Oracle run by a good DBA is fast fast fast. I don't have benchmarks for you. But I have personally migrated an application from MSSQL 2000 to Oracle 9i. I have more experience with MSSQL than I do Oracle (and so you could rightly infer that at first, my coding practice was optimized toward MSSQL which is in many cases the opposite of how you code for Oracle), and yet my application runs much, much faster on Oracle. I chalk it up, in part, to the efficiency of the indexing. The b-tree indexes in Oracle are just awesome. And now that I actually understand how to really tune a query in Oracle like I do in MSSQL, I have to say that Oracle provides better tools to enable you to tune. The explain plan alone, when you really understand it, is hands down better than, say set statistics io on and set statistics time on in MSSQL. And that's not even getting into TKPROF.
Maybe your real world experience says the opposite of what I just said, but in the corporate environment (like at work) I wouldn't even think of using anything other than Oracle, not out of prejudice, but based on years of experience. I'd like to try MSSQL 2005, though. Always willing to give them another shot.
But I have also used Oracle DBs admined at let's just say, a less-than-competent level, and it's quite horrid. Oracle has to be done well, and paying a real DBA is costly. Enter MySQL.
blah blah blah
Interestingly, despite the fact that I almost never recommend MySQL, I do agree that the 8 arguments opposed were not that wel thought out.
My comment to the article was:
First, I do not recommend MySQL frequently and I figured I would explain why. Although I have no formal training in database design I consider myself more educated in these matters than the average developer.
The basic issue is that, until recently, MySQL has avoided being a classical RDBMS. Instead, it has been developed as a quick and dirty data storage system with an SQL interface. While this is great for some kinds of applications (light-weight web content systems), it breaks down quickly when you need to have many different applications (some commerical, some inhouse) running against the same database. Even MySQL 5 does not get away from this concern entirely (even though the features now exist, enforcing them by the RDBMS is still problematic).
Basically-- if you want a rapid development storage device with an SQL interface for a single application, there is no reason not to use MySQL (aside from the standard Gotchas). If, however, you want to have a more intelligent database which mathematically represents your data as well as possible, and displays these properly to many different client apps, it is still not adequate. Note that the former case has a nasty habit of evolving into the latter case.
LedgerSMB: Open source Accounting/ERP
I only use the most recent version of MySQL, and I have the exact opposite perspective. MySQL does what a database is suppose to do really well - simple relational queries onto data. MySQL's transactional processing; the ability to set a savepoint and then commit or rollback, seems flawless to me.
Oracle on the other case, seems to be doing exactly the opposite of what a database is supposed to do - it's encouraging you to push more and more of the application layer into the database (first plsql, and now Java at the database layer?).
I just want to create tables, select, insert or update data. Not much else. That's what Codd truly intended. Codd would roll over in his grave if he saw the bloated mess that Oracle is today. And you can design a horrible denormalized schema in Oracle just as much as MySQL - neither force any form of normalization at the RBDMS level. (Some applications merit denormalization)
Not to even mention the absolute shameful way Oracle considers, manages and patches security issues.
MySQL is a simple, free relational cruncher. I can't believe a true finance architect considers Oracle more robust that MySQL, especially when its comes to security.
Horns are really just a broken halo.