Databases versus Programming Languages

Ovid on 2007-04-05T14:24:33

In response to a query from someone, I found myself explaining this (paraphrased):

You know I'm a Perl programmer. I teach the language, I sit on the Steering Committee of the Perl Foundation, I've been published on the language, yada, yada, yada. Despite all of that, I think the choice of the correct database is more important than the choice of programming language. Databases, even small ones, really are that important. Don't use MySQL.

If this guy said he was going to do all of his work in PHP (and he might), I'd be disappointed. If he settled for MySQL "just because", I'd be disgusted.


always something more important

link on 2007-04-05T15:17:28

Whatever lesson you learn there is always a more important one.

Today I learned even if your going to use php and mysql never store monetary values in euro as a floating point. Actually I knew this already but I'm fixing something by someone who didn't.

Answering the question

sigzero on 2007-04-05T20:24:59

If the answer to the question is "MySQL" you are not asking the right question. : )

Re:Answering the question

pudge on 2007-04-06T00:00:29

If the answer to the question is "MySQL" you are not asking the right question. : )
I see the smiley face, but MySQL has served Slashdot extremely well over the years. The proof is in the pudding, no?

Re:Answering the question

sigzero on 2007-04-06T11:51:01

Thank you for noticing the smiley face.

I would have to agree here. MySQL has warts? Really? Sure it does. That doesn't mean it isn't useful in certain situations. MySQL would not have become as popular as it is if it was crappy and didn't perform well in the area it was designed to run.

Re:Answering the question

Aristotle on 2007-04-06T15:39:33

MySQL succeeded because historically it was easier to install and faster than any libre RDBMS, not because it wasnߣt crappy.

Re:Answering the question

sigzero on 2007-04-07T03:30:45

I am not arguing that...but I think you will actually find people who actually like and prefer MySQL. Such is the way of things.

Re:Answering the question

vek on 2007-04-08T09:20:27

The fundamental reason we chose MySQL was out of the box replication. Now, this was a couple of years ago so other open source RDBMS might have caught up by now but lack of replication did prove to be a major showstopper.

Sure, for small apps, lack of replication is usually ok and a single DB server works just fine. When you're working on something a little bigger and you find yourself with 30+ DB hosts sitting behind a load balancer, you will be extremely happy with the replication options available to you in MySQL.

Again, I haven't really kept up with the advances other open source RDBMS have made in the replication arena so perhaps MySQL is not the only game in town nowadays.

Re:Answering the question

TeeJay on 2007-04-11T12:57:44

I don't think any of the other major libre RDBMS come with decent and/or out of the box replication.

Postgres replication is still a 3rd party add on, and it doesn't come with commercial support either, oh and it can be backwards incompatible in undocumented ways between releases.

Also it corrupts itself unless you vacuum the databases and is a resource hog.

Despite all that it is still the right choice for some projects, just as mysql is for others.

Re:Answering the question

jplindstrom on 2007-04-06T09:37:24

Or rather, chances are you're not asking the question you think you are.

For certain problems it's obviously a good choise (in my experience it seems those problems are pretty rare though).

Re:Answering the question

TeeJay on 2007-04-11T13:02:07

Right because :
What libre RDBMS has Commerical Support, proven and reliable replication and backup and a decent GUI?
is obviously such a wrong question.

I work with MySQL and Postgres almost exclusively and have to say that 9/10 times I would choose the former over the latter - especially if I'm clustering.

For all the talk about MySQL corrupting data it remains anecdotal and hasn't really been seen in production, fail to vacuum your postgres however and that's your data corrupted or lost.

Re:Answering the question

chromatic on 2007-04-11T18:49:53

That fits my experience as well. (Also, as a matter of personal preference, I don't care for the PostgreSQL CLI.)

Re:Answering the question

Ovid on 2007-04-11T20:55:52

For all the talk about MySQL corrupting data it remains anecdotal and hasn't really been seen in production...

Did you mean that you haven't seen it in your production environment? I get hit with this all the time and it's terribly frustrating to get pulled away from real work only to find yet another bit of code I have to patch because the MySQL developers didn't think data integrity was important. I know I'm not the only person with this problem.

Why not?

Frog on 2007-04-10T20:28:11

I honestly don't follow your explanation.

Re:Why not?

Ovid on 2007-04-10T21:44:11

That's because I've been complaining in this blog about similar issues long enough that I kind of take it for granted that the background is known. That's a bad habit and I thank you for bringing it to my attention.

I started to answer your question but the answer went on long enough that I felt a separate journal entry was appropriate.