God Uses MySQL

There was a lot
of reaction to my recent post about
MySQL at Sabre, most of which I don't have the time or interest to
respond to. Too many people just Don't Get It and Never Will.

But I was inspired to visit the church sign
generator and make the image you see with this post. I think it's
amusing. :-)

Anyway, life would be so much easier if people stopped trying to
think of MySQL in terms of Oracle or PostgreSQL or MSSQL or DB2
or... other database servers. It's none of them. It does many things
they do not and doesn't do things they do. It satisfies different
needs.

And, finally, those who want to argue that "a real database server
should do ________ or ________" don't get very far with me. I don't
care what you think a product should do in some abstract general
terms. I care about how MySQL fits the needs of people I work with.
Often it does. Sometimes it doesn't. And I have little problem
figuring out the difference.

But, hey, if you feel like bitching MySQL, I won't try to stop
you... But the recovering catholic in me knows that you'll probably go
to hell for it.

I just don't think I'll ever understand why these people have such fervent hatred for MySQL. I use MySQL to run a lot of websites on. But I also administer a fairly large Oracle database. I see where each has its strengths. And yet I still prefer MySQL for most things.

I'll be the first to admit that I have a bias towards PostgreSQL for db projects. I'll also admit that it isn't always the right tool for every job. In other cases either one could be used. As Jeremy already mentioned, each have different feature sets so they also have different strengths and weaknesses.

It's easy to ignore the strengths of the other when you are used to only using one.

I sometimes find that the people who start these holy wars are never experts in both databases. They use something like MySQL and go "Oh I hate this piece of s*it, it isn't anything like PgSQL! I hate it because it doesn't support doing s*it like this, and it sucks because I don't want to take the f*cking time to learn it."

And thus, they go on a crusade, trying to tell everybody how their database is better.

The last time somebody told me that MySQL sucked, I told him to shove..well that isn't appropriate for the children listening. The guy knew nothing about how MySQL worked, or what it involved. Instead he just wanted to say that it just sucked because he didn't know how to use it.

Anyway, use your own damn database, and i'll use mine. Thats all I say to them and go happily along my way, building my project.

If MySQL were such a hellfire fantastic database, it'd make me a better sandwich. I mean, really, the toast was burnt in a few spots and the lettuce was all wilty.

Granted, Oracle wouldn't make me a sandwich until I bought the $53,000/year Sandwich Development Kit license (which featured an 18 year old kid showing up with a bag of wonderbread) and the Postgres Sandwich API set is still in pre-release, but that's purely beside the point.

I don't hate MySQL - I'm just shocked at how profoundly bad it is. I honestly think that if Microsoft produced this product there would be no end to the bitching about its flaws, but b/c it's open source it is somehow immune from well-deserved criticism.

I also object to those who try to cast this as a religous or zealotous debate. It's not. FreeBSD -vs- Linux is. PostgreSQL -vs- MySQL is not. You just can't compare the two. I don't object to MySQL because it doesn't act just like PostgreSQL; I object to it because it is a horrible SQL database and shows little sign of improving in the future.

It is precisely because I know too much about it and how it works that I object to it. The multiple table types are a horrible idea - the hallmark of the relational model (of which all SQL databases are a pale shadow) is data independence from the physical layer. And at the logical layer, users should not have to worry about things like "Does Table A support transactions or referential integrity?"

But even more distressing is MySQL's penchant for making silent modifications to a database. It will silently convert columns from one type to another, silently truncate integer values, silently create default column values, silently create a MyISAM table if you requested an InnoDB one (in some cases), silently create a primary key, etc. Factor into this mess its horrible consistency checking (e.g. the lack of CHECK constraints and the almost total lack of range checking in the DATE datatype), and you have a disaster waiting for happen.

I don't want to have to write application code that double checks every insert to a numeric column to see if MySQL truncated it silently. That's just asinine to even suggest as correct behavior, yet MySQL forces you to do just this. And this is just one example of it's ridiculous behavior.

Please note that none of these issues arises from thiking of MySQL in terms of any other database. Nor are they a result of thinking what a SQL DBMS should do in abstract, general terms. They're specific examples of unacceptable behavior that leads to high risk of data corruption. In a nutshell, I simply don't trust MySQL to reliably store data and protect its consistency.

I wish the majority of MySQL proponents would admit that they don't want a database, but instead a filesystem with a SQL interface.

What MySQL (or MaxSQL) should become IMHO:
It's fast and light right now, and should remain fast and light. Only ONE feature should be added, the ability to load or compile modular functionality like in Linux.
Want views (or sps or triggers or, transactions or the "make toast" feature...) ? Run make menuconfig and either compile it in or load it as a module.
It would be the ideal database for the multi-db-platform lowest common denominator application vendor (none of whom use stored procedures for example).
Resist the bloat!

Derek, regarding your criticism of MySQL (which is incredibly valid), it will fall on deaf ears. Remember, at one point the creators of MySQL didn't even enforce referential integrity (the only intertable integrity rule that most SQL DB's follow anyway) which you can inspect via this link http://sunsite.univie.ac.at/textbooks/mysql/manual.html#Broken_Foreign_KEY.
If the creators of MySQL made such a resounding failure (mostly because of a lack of DB fundamentals) in not implementing keys, it's mostly cause it's cookbook mode programming, which I'd bet is the case. You visit dbdebunk BTW?

i'll disagree with you to a point. thinking that type (and resultant value) coercion is Ebil(tm) is mostly a result of having a rigid view of what an RDBMS should be, the same way static/strong/dynamic/weak typing language zealots deride the languages which use a combination that disagrees with their preference. to me, this coercion isn't useful and, in cases where it's quirky (many), it's slightly annoying. yes, it leads to errors, but only for those who aren't familiar with mysql and only once (unless the person in question is an idiot, in which case all is lost anyway). note that a lot of other rdbmses, notably oracle, have a plethora of quirks of their own.

lack of foreign key constraints is only a problem if you need them. when working with rdbmses that support it, i've often (though not always) found them getting in the way.

this all boils down to the application and the worldview. most of the stuff i work on (very high traffic web apps) use an rdbms mostly as an indexed, persistent datastore - i could easily (and would, if a solution that worked for me were available) replace most of the rdbms usage with a distributed write-back hash table.

this is not true for many, most likely very much not true for you; that does not mean it can't be true for anyone. right tools for the job and all that, provided the person making the judgement call has a good understanding of the job and the criteria.

on June 25, 2006 04:01 PM

Disclaimer: The opinions expressed here are mine and
mine alone. My current, past, or previous employers are not responsible for what I
write here, the comments left by others, or the photos I may share. If
you have questions, please contact
me. Also, I am not a journalist or reporter. Don't "pitch" me.

Privacy: I do not share or publish the email addresses
or IP addresses of anyone posting a comment here without consent.
However, I do reserve the right to remove comments that are spammy,
off-topic, or otherwise unsuitable based on my comment
policy. In a few cases, I may leave spammy comments but remove any
URLs they contain.