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
"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? ;)
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. :-)
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.
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
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.
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.
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.
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.)
