The problem is that very few people have actually used both MySQL and Pg in major performance-sensitive applications, so it's hard to get a good comparison. I have used Pg, but not as much as I've used Oracle and MySQL.
I can tell you a few things I like about MySQL, even though I can't really compare them to Pg in a meaningful way. I like how easy it is to administer. I like how fast the InnoDB storage engine is (faster than MyISAM for most of the work I do, even with transactions and foreign keys). I like the excellent documentation.
And finally, I like the fact that I know other people have done very serious work with it and succeeded. Yahoo, Google, Craig's List, LiveJournal... all of these companies use MySQL, and handle much more data than I need to. That gives me confidence that it can handle my work. | [reply] |
There are certainly some big mysql success stories, but they tend to be in applications that aren't just that fussy about things like data integrity. Google is a case in point: they're doing really well with replicated myisam tables, but if something weird happened to the data no one is likely to even notice. It's not like, say, handling banking transactions.
| [reply] |
| [reply] |
I, as a non MySQL user, would like to hear some answers to another question: why is MySQL better than PostgreSQL? Or, better, are there applications/environments in which MySQL is preferable to PostgreSQL? And why?
I'm by no means an expert either, but this is what I read multiple times:
When you have data this doesn't change very often, and you make many simple queries, MySQL (with MyISAM backend) is blazingly fast.
| [reply] |
If those are the only advantages, then MySQL is a waste of effort. If you rarely have insertions, deletions, or updates and you have a high volume of simple queries then OpenLDAP will not only have MySQL's lunch but will hand Postgres the empty tray and smack Oracle on the behind as it whistles and dances out of the cafeteria.
| [reply] |
Something I like about PS over MS is its sequence support. At the same time I like MS better in some ways for the same issue because it has auto_increment instead and it is almost all I ever need and it would be a drag to have to use an extra table (not sure it's a full fledged table, but you get the idea) every time. The same goes for the data type ENUM (not sure if PS has SET).
| [reply] |
At the same time I like MS better in some ways for the same issue because it has auto_increment instead and it is almost all I ever need and it would be a drag to have to use an extra table (not sure it's a full fledged table, but you get the idea) every time.
It's not any kind of a table, it's a sequence, which consumes only a handful of bytes, pretty much exactly like auto_increment does. The big advantage of a sequence over auto_increment is that if you need to you can use more than one sequence in the same table, or share a sequence between tables, which you can't do with MySQL (or couldn't do the last time I looked at it anyway)...
The same goes for the data type ENUM (not sure if PS has SET).
Not sure what you mean by the ENUM, since PostgreSQL does indeed have ENUM, just not in the backwards column-level way MySQL does it, which forces you to redefine the enum in every column you want to use it, even if it should be the same for all those columns.
# MySQL
CREATE TABLE color_choices (
foreground ENUM ( 'RED', 'GREEN', 'BLUE' ),
background ENUM ( 'RED', 'GREEN', 'BLUE' )
);
# PostgreSQL
CREATE TYPE colors AS ENUM ( 'RED', 'GREEN', 'BLUE' );
CREATE TABLE color_choices (
foreground colors,
background colors
);
And while PostgreSQL doesn't have SET, it does support array data types, which get you pretty much the same end result, with less work.
# MySQL
CREATE TABLE color_choices (
favorites SET ( 'RED', 'GREEN', 'BLUE' ),
least_favorites SET ( 'RED', 'GREEN', 'BLUE' )
);
# PostgreSQL
CREATE TYPE colors AS ENUM ( 'RED', 'GREEN', 'BLUE' );
CREATE TABLE color_choices (
favorites colors[],
least_favorites colors[]
);
Also, if you like SET, you should be sure and read The MySQL SET Data Type, especially the section entitled "Why You Shouldn't Use SET".
| [reply] [d/l] [select] |
| [reply] |