8 Reasons Not To Use MySQL (And 5 To Adopt It) 288
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."
How can the BSD be "too open"? (Score:5, Insightful)
Re:How can the BSD be "too open"? (Score:5, Insightful)
Re:How can the BSD be "too open"? (Score:4, Insightful)
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:Warning: mysql_connect(): Too many connections (Score:5, Insightful)
Re:Reasons not to use MySQL? These are stupid reas (Score:4, Insightful)
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.
lame "bias" argument (Score:3, Insightful)
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
That's not the target audience (Score:3, Insightful)
Re:oooo, goody (Score:4, Insightful)
It boils down to corporate culture.
Re:How can the BSD be "too open"? (Score:5, Insightful)
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.
Horribly written article (Score:3, Insightful)
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... (Score:5, Insightful)
Invalid use of the GPL? (Score:2, Insightful)
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?
Supports Cutting Edge Technology (Score:3, Insightful)
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:That's not the target audience (Score:5, Insightful)
If you are in any position where you are choosing between databases, you have three cases:
Sorry about the M.P. reference there :o)
Seriously (Score:3, Insightful)
Re:The 8 reasons not to use mysql (Score:4, Insightful)
Re:#2 is not an issue with enterprise applications (Score:3, Insightful)
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.
Why Not Use MySQL (Score:2, Insightful)
Re:It gets worse... (Score:4, Insightful)
Re:The 8 reasons not to use mysql (Score:4, Insightful)
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 [blogspot.com].
Re:That's not the target audience (Score:3, Insightful)
5. You have delegated the decision to a well-funded, trusted team of veteran IT decision makers.
Businesses live and die by information, so the severity of your list of relatively insignificant defects rather depends on the criticality of the data in question. When lives are at stake (economically, physically or medically), when every hour of system downtime costs your operation tens or hundreds of thousands of dollars, decisions are based on higher level concerns. The integrity of the data is paramount. Data moving between mart and warehouse needs to cost as little as possible.
I'll then hire DBAs who appreciate the chosen technology for reasons that matter to them. If it's MySQL, maybe these are DBAs looking for an opportunity to not only use but enhance the product, and that's fine with me.
Not to rain on your parade, but _you_ are the suspect DBA the author recommended CIOs ignore when weighing the facts -- that is not to vet his weakly argued list of criticisms, I just couldn't let these posts sit at +5 unchallenged.
Re:I tried to pay attention. I really did. (Score:1, Insightful)
Also, I'm a rubber chicken. Squeak.
Re:Easy To Use (Score:1, Insightful)
Re:Invalid use of the GPL? (Score:4, Insightful)
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:I tried to pay attention. I really did. (Score:2, Insightful)
Re:Reasons not to use MySQL? These are stupid reas (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:4, Insightful)
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.