Posted
by
Zonk
on Friday May 25, 2007 @03:48PM
from the for-every-product-turn-turn-turn dept.

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

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.

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.

One trend I have observed but for which I have no hard data is that formally trained DBAs tend to prefer a proprietary RDBMS such as (most commonly) Oracle. I suspect that those with formal training and experience as a DBA (rather than as a software developer) tend to have a bias toward proprietary systems.

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.

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.

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.

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!

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. Therefore if you use this description to write a program, you must release your program as GPL.

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?

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.

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 [blogspot.com].

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.

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.

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.

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.

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.

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.