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."
Oh, boo-hoo, dual-license bad!
The rest of the article is equally stupid. For example, "If you already own proprietary licenses ..." has NOTHING to do with whether Mysql is a good fit or not. Next it will be "I hae Pepsi in the fridge; I really want a glass of free cold water or a bottle of Coke right now, but I'll buy some more Pepsi instead seeing as I've already standardized on it".
NOW
Seriously, the articles do nothing more than point out the *best places* MySQL may or may not work, not that it is better than anything.
One size yet again does not fit all.
Hmmm..where's my Model204 manuals...?
1. MySQL Uses the GPL
2. MySQL Doesn't Use the GPL
3. Integration With an Existing Environment
4. Product Maturity
5. Feature Set Maturity
6. Availability of Certification
7. Corporate Considerations
8. Perception of Scalability
They all have *some* merit, but all are very dependent on your situation. 1 and 2 seem to cancel each other out, as in if #1 is an issue for you, #2 probably wouldn't be. #3 is sort of weak, arguing that if you already have many other databases, adding yet another different system is detrimental. That's not an argument against MySQL, but against disparate systems altogether. The rest of the issues are matters of degree. "While MySQL does have a certification training program, its training availability is not nearly as widespread as for, say, Oracle or MS-SQL Server." True, but if you're comfortable with the level of quality of certified MySQL people, then go forward. It'll contribute to the general upward spiral of adoption, hiring, certification and so on. MySQL is going to keep growing, it's just a matter of how quickly and in what directions.
P.S. Printable version here -> http://www.cio.com/article/print/113111
creation science book
close(rantPage);
System.out.println("Nothing here to see. Please, move along...");
The pro-MySQL "guy" can't pee standing up, either. "He" is a she.
The anti-MySQL guy is Canadian, though, so he probably doesn't pee standing up either. Lots of beer -> floor -> bladder evacuation. I kid, I kid...
Someone need's to slap this author with large trout. There are many reasons NOT to use MySQL, of which this article touches on only one. For example:
--Innodb scaling across multiple processors (MySQL bug ID 15815, still not completely fixed)
--Limit of 1024 current transactions ( MySQL bug 26590)
--Terrible performace when running MySQL Cluster
--Single threaded mysqldump exporting and importing (recently fixed in 5.1)
--Single threaded replication (making many changes? Don't count on it if you're running replication)
--Poor handling of subselects
--ineffecient ORDER by and GROUP BY
--Poor quality filesort algortythm (want to see your $20,000 dollar database server die?)
--better performance in 4.1.x
Let's also mention that 5.1 has been out in beta for years now. When is it ever going to ship? MySQL now is proclaiming fixes in 5.2, and 5.1 isn't even on the board to ship yet.
With all that, and more, I'm surprised this author could only come up with "it isn't made by Oracle" and "product mateurity."
*disclosure -- yes, I play with MySQL databases all day long in large high use production environments. MySQL is great for small systems, but there -are- some problems when running on large enterprise grade systems. It'll get there
/. is a commercial entity. goto slashdot.com
No, that's part of the "8,573 reasons to not use PHP" article.
Done with slashdot, done with nerds, getting a life.
Oh goody! I'll help get things going:
Happy Memorial Day!
The more advanced RDBMS engines have OLAP/Datawarehousing support built in. For example, in SQL Server, thats SSAS, and it works wonderfully well, and is as integrated as it can be. Oh, one can argue that its technically a "separate" database, but from an installation, licensing and development point of view, they're one and the same. (Analysis Services also happens to be the market leader in that department...).
Thats just an example, and while thats Microsoft, I'm sure there are plenty of non-Microsoft equivalents for relational databases and olap cubes being integrated as one (and a half?) product.
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.
Just junk food for thought...
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
Many applications need a small to medium size database that contains important but non mission-critical data. MySQL is perfect for those applications. No licensing hassles, no funds requests, no major administrative overhead. I don't have enough experience with MySQL to recommend it for a really critical database, but we do have plenty of need for smaller databases that we can set up quickly. I certainly don't see spending a lot of money on SQL Server (which we are doing) or any other big commercial server to run a bunch of small databases.
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.
Yes, my arguments may be technical in nature, however the arguments in the article are worse than straw-man arguments. I'm surprised the author didn't mention that MySQL doesn't cost $20,000 per processor, therefor must be bad. Even given the intended audience (who, as you suggested, may not be extraordinarily technical) the pro-MySQL author did a much better job laying reasonable arguments.
You mention Excel jokingly, but I know some companies which maintain large databases worth of information inside of Excel (statistics on hundreds of applications for hundreds of devices on dozens of networks, reported daily ) because no one wants to write a script to input data into a database.
/. is a commercial entity. goto slashdot.com
Last time I checked, DB2 was more scalable than Oracle (less performance hit as you stuffed the database) and both Sybase and SQL Server were faster.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Just keepin' it real. Gotta love the internet.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
but oranges are sticky... and very inconsistant, sometimes you get really sour ones, no real warning sign of that. apples at least you know what you're getting... if it's squishy, it'll be gross and brown inside.
unless you include green apples in that debate, those ones can be pretty effin random. i don't like those ones much.
hmm... i need to do some more considering on this debate.
come to think of it, christmas oranges rock the house... so i guess if your comparing christmas oranges to green apples, then yeah, oranges > apples. but i think on average i'm still going to go with apples > oranges just based on sticky fingers and the potential of unexpected sourness.
~/.sig: No such file or directory
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.
This article comes from CIO website so I think that it if fair to say that they are most interested in applications for the enterprise. Enterprise applications don't bundle the database. They may require a certain database vendor product/version or a small set of database vendors but they don't bundle the database with the application. This is true whether or not you use SQL Server, DB2, Oracle, MySQL, or PostgreSQL.
IANAL, but IMHO there is no legal restriction to selling a commercial, closed source application that requires MySQL as long as you don't include the MySQL application with it. This isn't a problem for enterprise applications because businesses that need such applications already have sufficient IT experience to run the vendor specific database that they are going to accept. If a company doesn't have sufficient IT experience to do this then they are going to have to go the SaaS route. Their are not going to be able to manage the application even if it did come bundled with a vendor specific database product.
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?
That depends entirely on the platforms you happen to run them. DB2 on NT (what used to be called "UDB") is a joke; DB2 on OS/390 is pretty much what defines a "big-iron" database. Oracle on NT is nowhere near as good as it is on Solaris. But Sybase on NT is actually quite good - almost as good as SQL Server on the same hardware. Sybase 12.x on HP-UX is also quite good.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
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.
But some +5 commenter pointed out what the 8 points against were, and they sounded lame. Another commenter actually listed 8 real problems with MySQL. But no matter how you slice it, the biggest, baddest, most ass kicking websites on the planet* are powered by MySQL. So... uh... deal with the reality. MySQL isn't going away.
* Google.
* Yahoo.
* Digg**.
** Yeh, I'm the Digg DBA.
fifth sigma, inc.
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"
--Poor quality filesort algortythm (want to see your $20,000 dollar database server die?)
What does Al Gore have to do with this?
I recently started looking into databases, and I asked a bunch of friends. All the experienced ones gave roughly the same advice: If you don't have time to read directions, just throw something together with MySQL. It'll be okay. PostgreSQL would be better.
So I took the extra ten minutes, and I'm pretty happy.
Every large site I know of that uses MySQL has had scaling problems of one sort or another under load, usually to do with trying to handle multiple writes to the database. At least a few people have simply swapped in PostgreSQL and seen problems disappear instantly. One friend did performance testing, where what he found was that MySQL was faster for small sets of clients, but that it slowed down faster, and that for largish N, he couldn't get it complete the test on the available hardware, but PostgreSQL just ran.
Having set up both a few times now, and having debugged problems with both, there is simply no way I'd use MySQL given any choice at all. It runs, but it feels accreted rather than designed. I know, Cathedral and Bazaar and all that... But there are times when you really do want the feeling that someone considered something up front.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
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.
PostgreSQL (AWESOME and FREE)
And PHBs can spend budget on paid support.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
> Not all database types are fit for all purposes. Relational databases for instance are bad for data mining/warehousing
> due to poor query performance but good for data entry due to high transactional performance
Your information is incorrect:
1. relational databases have been used for warehousing and reporting (data marts) for 15 years - and are used for more than any other solution for this purpose. Ok, sure you've got a lot of OLAP out there, but there's probably almost as much Relational OLAP (ROLAP) via Microstrategy, etc as there is true OLAP.
2. Take db2 for example, it:
- support three different forms of range partitioning (union-all views, multi-dimensional clustering, and range partitioning)
- supports hash-partitioning of the data across many servers - think "beowulf cluster"
- given the two above you can spread your data across 100 4-way servers, each with fibre access to a heavily-cashed SAN.
- Now when you issue a query db2 will spin up all 100 servers - each hitting its own local piece of the data (not 100 copies of the whole data, but each server with 1% of the whole).
- Because it also supports range partitioning each server is probably only going to scan 10% of the total data in a typical query.
- Because it support query parallelism it'll split each query on each node into four separate pieces (getting near-linear performance speedups) - now you've got 400 cpus working.
- Because its optimizer is about the best one on the market - it isn't going to auger itself into the ground on your 100 line sql query.
- That should allow you to crunch down a billion rows to your 24 row output in couple of seconds at most.
- Of course, it's also smart enough to rewrite your query to automatically hit any summary table that could speed the query up. So, it may only have to scan 2400 rows - and may return the results in 0.001 seconds.
3. The point is that warehousing, reporting and analytics work very well in a relational environment. But you need to pick your products well. If you want to handle terabytes of data you can put it in MySQL, SQLite, MS Access, Foxpro, etc - if you really had to. But, life will be *far* easier if you put it into a product that can handle the volumes much better.
Tina is dead bang on with the TCO commnet; We pay more for Oracle support than we pay two Certified DBA's.
Brent's comment about "ignorance" of workers not knowing a company has a site license for propertiery systems is not a technology fault, but a management fault. That cannot be properly consider a fault of the technology.
Seems to me to be a send up. A trial ballon to support a future brochure slick about why paying $$$ for an RDBMS makes sense and why something "Free" isn't. We all know that using open source isn't free unless you have unlimited staff time and don't count system administration costs against a particular project. Open Source CAN cost a lot more than a closed source system, but it's not something I've seen. I'm sure there are examples, I just don't know of any.
There are also times when open source doesn't make sense. Like in situations of unlimited libility in case of failure. Take a nuke reactor. Say you use open source products to control that reactor, and it melts down because a pump failed to start, a valve was incorrectly closed, and humans didn't follow proceedures. Automatically, it's the fault of the open source product, obviously, because you were too cheap to go buy "good" software.
Until the human race as a whole can value a gift freely given by a stranger, it won't grow much past it's current point.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
This page has a list of MySQL gotchas
http://sql-info.de/mysql/gotchas.html
Some of my favorite are things where MyQL accepts values it shouldn't and it doesn't throw an error. For example you can insert a 0 into a date field, 30000000000 into an in column (it will just ignore the higher order bits.
MySQL is OK for quick and dirty, but it will always be dirty. If you want MySQL to be decent:
1) Set it up with InnoDB and make that the default table type. MyISAM should only be used for data warehouse tpye applications where you are doing a lot of IO and its OK for the DB to be down for hours while you recover your corrupted MyISAM tables.
2) Set the strict sql mode in the my.cnf. I don't remember exactly what the parameter name is, but you want MyQL to throw an error if you throw stupid values at it. Otherwise it will accept wacky values and you'll end up debugging it later.
3) Set the default character set to UTF-8 if you can. This can be a bear but its worth it to be able to handle foreign characters.
4) Avoid the fancy "features" if you can. The old features still have unresolved bugs and it isn't going to get any better with more and more storage engines going in.
5) Monitor the performance constantly and be prepared to partition your data. Scale out isn't always as easy as it sounds.
I've RTFA, and I got to say it is complete crap. OK, actually I only read the first page, and the reasons I read aren't convincing enough. Beside I dislike websites that make you go trough 8 pages at one paragraph each of content only to get lost in their completely cluttered up design and in your face advertising.
~ In Trust, We Trust ~
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?
8 is more than 5!! Looks like I won't be using MySQL!
Did you ever notice that *nix doesn't even cover Linux?
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 will take a crack at this.
With a traditional RDBMS, you define your data essentially using a pseudo-mathematic model, assign data constraints and triggers to ensure that the model is not violated, and add views to provide handy ways or putting the data together. You may optionally add stored procedures as a functional interface to that model.
Until 5.0, MySQL didn't even try to be this sort of database. Even in 5.0, you only get real data constraints, triggers, etc. on some types of tables, and strict mode (which does actual data type checking) can be turned off by the application. MySQL still does not compare well to traditional RDBMS's in their home turf (though PostgreSQL, Ingres II, and to a lesser extent Firebird do compare reasonably well-- Firebird to a lesser extent just becuase of some interesting cases involving NULL's).
In fact, MySQL is almost, though not entirely unlike Codd's idea of an RDBMS. MySQL is not something to consider for your RDBMS. Period. End of story. It is not worth it.
However, if what you want is a simple data storage engine for your one app with an SQL interface and many of the features from real RDBMS's, MySQL is not bad. It is a remarkably flexible software development tool with many very useful. It just is not a substitute for a real RDBMS (where, for example, the server must authoritatively and robustly provide data sanity checks).
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.