MySQL is so late-90s. Everything that MySQL used to be good at has now been beaten: DBD::SQLite for the low-end, and DBD::Pg (to PostgreSQL) for the high end. Please don't waste your neurons learning about MySQL unless you are supporting legacy apps or legacy thinkers.
This reminded me of something Mike Hillyer wrote:
First of all I understand that the tool/language/OS you use is the cat's meow, and I am really happy for you that you found it. I also assume that you chose your new favorite tool/language/OS (lets call it TLO from now on) after carefully considering the costs, benefits, and other pertinent factors involved in a decision of such magnitude.
Now please afford me the same understanding and assumption.
[...]
I understand that you think MySQL is garbage. If you tell me so I will first assume you are a Postgres user. Listen up guys, get over the popularity contest. Every time Postgres or MySQL is mentioned on Slashdot it turns into a MySQL bash-fest. Oddly the MySQL camp never gets into a big flame-fest on Postgres, and we don't troll Postgres users like they do for things like Jeremy Zawodny's blog.
-- Stop Saving Me From My Tools! (via Jeremy)
I was thinking about what Randal said, and it's very easy to swap the tools around to get to somebody else's point of view:
Perl is so late-90s. Everything that Perl used to be good at has now been beaten: PHP for the low-end, and Java for the high end. Please don't waste your neurons learning about Perl unless you are supporting legacy apps or legacy thinkers.
I'm a happy Perl and MySQL user, both tools have advantages and disadvantages compared to other tools. I'm sure a different person would use a different toolset to solve the problems I solve with them. I'm just happy that we have these choices.
MySQL is there mostly from inertia now. Other than legacy compatibility, there's really no reason to use it. So for new starts, I'm trying to help set the record straight, in the NMS vs MSA manner.
Re:It's like "Matt Wright" vs "NMS" though
gav on 2004-02-28T04:21:25
I still don't understand your issue with MySQL. It's not like it's a big security risk which was the reason to avoid Matt's scripts. What is wrong with MySQL?Re:It's like "Matt Wright" vs "NMS" though
davorg on 2004-02-28T14:32:32
The main point in the nms vs Matt Wright thing was not the security issues (most of those have been cleaned up in even Matt's code), it was that people who knew Perl knew that Matt's programs weren't good Perl.
It's the same with MySQL vs PostgreSQL. People who know databases know that MySQL isn't a good database. Sure it does the job if your requirements are simple. It probably looks great if you're coming from something like MS Access, but if you're used to using a "real" relational database system like DB2 or Oracle then MySQL just doesn't cut it. It just doesn't have many of the things that people who design real databases see as essential. A few of the most obvious ones are:
* Transactions
* Sub-selects
* Stored procedures
* Referential integrity
Without these features you are just playing at database design.
I know that some of these are about to be or have recently been added to MySQL, but they've been in PostgreSQL for years. They are stable features in PostgreSQL but cutting edge in MySQL.
So if you want something which is basically a cut-down version of SQL for accessing data stored in very simple tables then ue MySQL. But if you want something that looks and acts like an Open Source version of Oracle, then PostgreSQL is the way to go.Re:It's like "Matt Wright" vs "NMS" though
gav on 2004-02-28T16:17:58
* Transactions
We've had transactions since 3.23.34a (with InnoDB)
* Sub-selects
* Stored proceduresMaybe what I generally do with MySQL isn't that complicated but I've managed to survive without both. Sub-selects are working in 4.1 and stored procedures in 5.0.
* Referential integrity
FOREIGN KEY added in 3.23.43b
There is a lot of interesting things on the horizon for MySQL users, especially due to the merging with SAP DB. You can use MaxDB which has a lot of these features working now.
Re:It's like "Matt Wright" vs "NMS" though
davorg on 2004-02-28T17:26:40
But, as I understand it, you lose a lot of the speed if you use them.We've had transactions since 3.23.34a (with InnoDB)* Transactions
Stored procedures are essential (IMO) if you will have more than one client application connecting to the database. Otherwise you'll have the same business logic implemented in different places (in, potentially, different languages).Maybe what I generally do with MySQL isn't that complicated but I've managed to survive without both. Sub-selects are working in 4.1 and stored procedures in 5.0.* Sub-selects
* Stored procedures
But I don't think it does anything other than document the relationships. You can still add a foreign key that doesn't have an associated primary key value or delete a primary key that has existing foreign key values.FOREIGN KEY added in 3.23.43b* Referential integrity
Sounds like it's getting there, but PostgreSQL is already there - and has been for some time. That's my main point.Re:It's like "Matt Wright" vs "NMS" though
chromatic on 2004-02-28T21:25:37
Sounds like it's getting there, but PostgreSQL is already there - and has been for some time. That's my main point.That's fair, but Randal's point is that SQLite and PostgreSQL have superseded MySQL at the things MySQL is good at. If I were to apply your rule above to that situation, I could fairly claim that SQLite and PostgreSQL are getting there but MySQL is already there and has been for some time.
Is that a facile analysis? Absolutely.
Still, the whole debate seems to be that "MySQL doesn't have these features! Well, okay, but they only just added them! Well, okay, but it doesn't have all! Well, okay, but they're not stable yet! Well, okay, but they haven't had them for years and years! Well, okay, but it's still a toy!"
It's really amazing -- you can win cool prizes by playing Bad and Increasingly Untrue Things People Say About MySQL Bingo.
Re:It's like "Matt Wright" vs "NMS" though
phillup on 2004-02-28T06:09:04
MySQL is there mostly from inertia now.
While I think this statement is a hundred percent correct... It is only half the story.
I have never used PostgreSQL, for one simple reason.
I have not needed it.
Inertial? Sure.
But, until the benefits justify the cost, it doesn't make sense to spend my time replacing something that "just works" for me.
Sometimes "good enough" really is...Re:It's like "Matt Wright" vs "NMS" though
chromatic on 2004-02-28T09:53:04
That's a terrible analogy. It's no secret that Matt's scripts are poorly written (is MySQL poorly written?), with no support (does MySQL have support?), numerous security flaws (is MySQL insecure?), and no active development (has MySQL stopped progressing?).
I'll tell you reasons to use it over PostgreSQL: better support on Windows, nicer client interface, better documentation, from the project itself as well as from third parties, and a much saner upgrade scheme. I also hear that its replication support is much nicer.
Hey, there are reasons to choose MySQL over PostgreSQL too, especially if you're already familiar with triggers and constraints, if you want to use the inheritable tables, or you're migrating from Oracle. Those are also good reasons.
It's not 1998 anymore, though. I think people deserve better explanations than "it's teh old b0rked!"
Re:It's like "Matt Wright" vs "NMS" though
pudge on 2004-03-02T21:12:21
Neither of the options Randal presented would be satisfactory for Slashdot: SQLite is too lite, and PostgreSQL is too slow. We have transactions when we need them (which is seldom), we don't need or want stored procedures. Lack of subselects sucks, but you take the good with the bad. So, whatever.
search.cpan uses MySQL. It's never been a performance star but, then again, neither has Perl. I also use MySQL for a lot of other stuff. The only gripe I have with it that I've begged Monty for rather shamelessly is the lack of cascading deletes.
And, Perl is very late 90s. Ruby, not PHP, is the future.
Re:bollocks
djberg96 on 2004-02-28T20:48:23
Finally coming out of the closet, eh? I'll look for you on comp.lang.ruby.:)
