The Fortune Magazine MySQL story I mentioned the other day (which is also being syndicated on cnn.com) has just been slashdotted.

Slashdot is a lot like a car accident on the highway. You know it's gonna be really bad, but somehow you can't stop yourself from looking (or reading in this case).

News flash, folks: MySQL has transactions. Yes, the ACID kind, just like Oracle and PostgreSQL. They've been there for a while now. Really. I've been using them quite happily.

It never ceases to amaze me.

The Open Source freaks can be so predictable sometimes. As expected, most folks seemed to have a 3 year old (or worse!) view of MySQL's features and limitations. And, as expected, there was a big "What about PostgreSQL?! It has more features!!!" contingent.

Reality check. It's not all about features. It's about the best tool for the job. For a lot of folks, MySQL really is that tool. Get over yourselves.

Posted by jzawodn at March 16, 2003 07:23 PM

Reader Comments
# Derek said:

"Slashdot is a lot like a car accident on the highway. You know it's gonna be really bad, but somehow you can't stop yourself from looking (or reading in this case)."

I've read that somewhere else. Was that also you, or are you quoting someone, I mean plagiarising someone? ;)

on March 16, 2003 07:35 PM
# Jeremy Zawodny said:

I've read it elsewhere, but can't recall who said it. It seemed so appropriate that I just had to use it.

If anyone knows who said that first, let me know. I'll glady attribute them. :-)

on March 16, 2003 07:54 PM
# Rob Speicher said:

Fucking. A.

on March 16, 2003 08:37 PM
# George Schlossnagle said:

I use Mysql a decent amount. I also use Oracle and have been know to dabble with Postgres. I agree it's about using the right tool for the job and that often that tool is Mysql. What I find annoying though is that the Mysql docs are rarely very forthcoming about it's limitations. It's almost never put as 'Mysql doesn't support X, if you want X wait till it's implemented or use another product'.

Take for example this gem from the mysql docs:

The FOREIGN KEY syntax without ON DELETE ... is mostly used for documentation purposes. Some ODBC applications may use this to produce automatic WHERE clauses, but this is usually easy to override. FOREIGN KEY is sometimes used as a constraint check, but this check is unnecessary in practice if rows are inserted into the tables in the right order.

That's an extremely narrow view of foreign keys and a lazy push of intergrity checking from the database (where it belongs, since it's data integrity) back onto the application.

Like I said, I use Mysql and I like it. I think it would be better to document features that don't exist as unimplemented/unwanted instead of attempting lame justification as to why I don't want.

on March 17, 2003 07:41 AM
# BDKR said:

I'm not sure why the hardcare Postgres people are SO negative about MySQL. There are a lot of good things about both, but I have to say that I can't see how Postgres could even get on the map without replication. MySQL's replication saved my arse last week. Yeah sure, Postgres has tons of tricks up it's sleeve, but those tricks would've been useless last week when the board went on the primary db!

Cheers,
BDKR

on March 17, 2003 01:05 PM
# Sterling Hughes said:

I agree with George. Its not that MySQL is bad, or feature-poor. MySQL is a great database, but there are many things it is not.

A *R*DBM for example.

MySQL is awesome for some purposes, it is a excellent DBM killer. :) It is easy to install, easy to setup and a very forgiving mistress. The problem I see is that the MySQL claims to be more than just a simple, albeit excellent, data management solution.

MySQL can of course, be an industrial grade RDBM, in 5-10 years, and when it does, great! But if you listen to MySQL PR, it already is, and that's annoying. Show me triggers, views, foreign key contraints, stored procedures, show them working reliably for 5 years. Currently MySQL cannot give PostgreSQL a run for its money: not as a RDBM. But most people don't need a RDBM, they need a flexible data container, and MySQL is pretty damn good at that.

on March 17, 2003 01:16 PM
# chromatic said:

Several regular Slashdot posters could write page after page of comments given only randomly generated headlines.

Me, I learned to read before I could write.

on March 17, 2003 07:41 PM
# yer fullovit said:

Yeah, MySQL gets more features by having to tack on stuff from other companies like InnoDB. Most mysql users have a 3-year-old view of PG. Even if it's not all about the features, I still can't think of a scenario where I'd use mysql instead of PG.

on March 18, 2003 11:55 AM
# Scott Marlowe said:

BDKR:

Replication exists in several different forms for postgresql, one of which is a commercial add on that is quite reliable.

Built in or not is inconsequential. Whether it works is all that counts, and it does.

I just run updates every night at midnight to the backup server. Since my main server has never gone down (watch it cook a mobo this week :-) I've never had any downtime, since Postgresql has never crashed. Not once. The null set, nunca, nadie.

Switching the backup server online manually has generally taken about 5 minutes or less in production testing.

I don't love or hate either database, but always felt like MySQL was cutting corners with my data (i.e. insert a numeric out of range and mysql just inserts the max numeric it can hold.)

on March 24, 2003 02:12 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.