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