Re^2: [OT] Why I don't use Mysql for new projects

[EvanCarroll]

I agree fully with this node. I love Postgres, and it is most certainly better than Inno for many reasons. But, these stupid posts fail to acknowledge anything MySQL has done right and instead they cherry pick the most-wrong way to do something and present it in such a biased fashion that Bill O'reilly would cry blood. If you want to compare apples with apples, compare the *newest* version of Postgres (8.3) with the *newest* version of MySQL and ignore the non-inno backends. It does surprisingly well.
Pg still has so much room for improvement, and it certainly isn't the easiest of the two to develop in. Though I would have to say, I've seen MySQLs "user variables" abused to do some pretty simple tasks that can be done with a simple Pg aggregate.

[doom]

If you want to compare apples with apples, compare the *newest* version of Postgres (8.3) with the *newest* version of MySQL

Cool idea. Why not get to work on it? Myself, I'd love to spend the next year working on database benchmarks and reliability tests just so I can have an informed opinion in a geek debate. Of course, no one will actually pay any attention to you, and by the time you're done the databases you're studying will have changed some more, but what the hell.

and ignore the non-inno backends.

You mean, pretend that most people aren't using the default?

It does surprisingly well.

Ah, so you do have some data? You've compared the results with both databases, then? What was surprising about your results?

Pg still has so much room for improvement, and it certainly isn't the easiest of the two to develop in.

And where would that "room for improvement" be, precisely? I can't imagine why you'd find it harder to develop for than any other database.

(Department of cheap irony: perlmonks.org hit a "database error" when I first tried to post this.)

[EvanCarroll]

Inno is the default for a backend *that requires transactions* and has been for a while. The assumption is simply that the most typical use of database will not require transactions -- which is probably true if you follow the mindset that a hash functions better as an api into a database. And, if your argument is on the lines of being informed costs too much time.. then just do us all a favor and remain silent.

MySQL has a pseudo-SQL interface into the DB which is more uniform for a new user. I'm also told from people that use MySQL replication that it is easier to manage -- and it works off the shelf without having to install a contrib module. MySQL still has more functionality in the CSV libraries. And, MySQL supported fts (without contrib modules) before pg. There are a ton of other things, like "AUTO INCREMENT" makes more sense than "serial" -- and if you give write access to a table in Postgres you assume you can insert into, but not if it has a serial datatype, because that creates a index. An Index is incremented on the write, therefore the index too has to be +w.

MySQL supports SQL extensions for mere convenience which Pg has a higher resistance to permitting. See "INSERT ignore INTO ...", "ON DUPLICATE KEY UPDATE", and