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."

Comments

How can the BSD be "too open"?

[DaleGlass]

In these situations, if the BSD license of PostgreSQL is still too "open," a commercial license is preferred.

This is plain bizarre. How can a closed license be preferrable to BSD, when BSD is basically "do whatever you want with it", including closing the source?

Re:How can the BSD be "too open"?

[Rycross]

Obviously giving the author credit for originally writing the code is just too demanding.

Re:How can the BSD be "too open"?

[RingDev]

And another gem FTA... "Whatever one might say about the strength of MySQL's backers, the fact that the company is not publicly traded means the financials are not required by law to be a matter of public record."

So we're going to have to trust the software company that won't show us their code, but will show us their books instead of the company that will show us the code, but not the books?!?

The 8 reasons are completely bunk, I thought I might actually learn something reading that article as we are about to increase our MySQL presence here, but that was a complete was of time.

-Rick

Re:How can the BSD be "too open"?

[DragonWriter]

And another gem FTA... "Whatever one might say about the strength of MySQL's backers, the fact that the company is not publicly traded means the financials are not required by law to be a matter of public record."

So we're going to have to trust the software company that won't show us their code, but will show us their books instead of the company that will show us the code, but not the books?!?

In business, this often makes some sense. The purchaser doesn't want to see and maintain the code, that's not their core competency. They want to be assured that, however, the vendor they get support from will be around to provide support in the future. So they are more concerned with the financials than the code.

Its just outsourcing in its original sense (before what used to be either "overseas outsourcing" or "offshoring" became the dominant definition): focus your company on its primary mission, and contract out for everything else.

Re:Warning: mysql_connect(): Too many connections

[DarkSkiesAhead]

Warning: mysql_connect(): Too many connections ?

That warning should really read: "Warning: crappy sysadmin" No reason to see it on a well-run site.

Re:Reasons not to use MySQL? These are stupid reas

[iknownuttin]

--Innodb scaling across multiple processors (MySQL bug ID 15815, still not completely fixed).....

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.

That's not the target audience

[Doug-W]

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.

Re:That's not the target audience

[EsbenMoseHansen]

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.

If you are in any position where you are choosing between databases, you have three cases:

1. You understand these issues
2. You have delegated the decision to someone who does
3. You are incompetent
4. You are toying around

Sorry about the M.P. reference there :o)

Re:oooo, goody

[Ucklak]

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.

Horribly written article

[knarfling]

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.

Re:Ready...Set...

[jrockway]

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!

Supports Cutting Edge Technology

[BrandonReese]

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.

Re:The 8 reasons not to use mysql

[TopSpin]

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.

Re:It gets worse...

[tomhudson]

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?

Re:The 8 reasons not to use mysql

[Ed Avis]

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.

Re:Invalid use of the GPL?

[Just Some Guy]

Because this is a GPL protocol, any product which uses it to connect to a MySQL server, or to emulate a MySQL server, or to interpose between any client and server which uses the protocol, or for any similar purpose, is also bound by the GPL.

Fiction: the protocol is GPLed. Frankly, that's just dumb; the GPL's scope doesn't include protocols.

Fact: the MySQL client libraries are GPLed. If you use the official MySQL libraries and wish to distribute your program, your choices are to buy a commercial license or release your code under the GPL. I am unaware of any non-GPL client libraries for MySQL, although I've never had a reason to actually look for them.

Basically, the author was mostly right, even if for the wrong reasons.

Re:Reasons not to use MySQL? These are stupid reas

[hobo sapiens]

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.

Re:oooo, goody

[einhverfr]

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.

Re:MySQL the db for people who don't understand db

[Heembo]

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.