Lennart Sorensen wrote on 31/10/2005 15:41: > On Tue, Oct 25, 2005 at 09:51:31PM +0200, Jean-Christophe Montigny wrote: > >>Well, I am afraid I'm not quite postgresql-literate, and I live by the >>(perhaps false) assumption that PostgreSQL and MySQL are more or less >>the same : open source database projects, except PostgreSQL are supposed >>to be "faster" in reading and "slower" in writing than MySQL, and that >>they roughly have the same capabilities.. > > > Postgres has much more complete SQL syntax support,
That might have been the case before MySQL 5.0, but as far as I can tell, now MySQL has the more complete and more standard-compliant support for SQL 2003. > and finer grain locking than mysql. It locks finer than a single column? > They are quite different in features and their target markets. That's for certain. I wouldn't try using Postgres with database replication (i.e. automatically keeping two or more databases in sync with automatic updates when the master is updated etc.) currently. MySQL has done this quite fine for some years though. Full-text indexes and real-time replication support (or lack of mature solutions for this) really are downsides of Postgres. > It is also easier to be fast writing if you lock the > whole table and prevent others from accessing it while you update > things. Slows down reading to stopped while you do a write though. True. But MySQL gives you the choice: MyISAM tables are fast in writing and might get slow if you concurrently try to read. InnoDB on the other hand is slower, but uses column-locking instead of table-locking. It's not really faster on reads than MyISAM if you do reads only, but it is faster on reads if you concurrently write to your tables. > Postgres does have quite a lot of support for triggers and events to > perform, although I have no idea how it compares to Oracle. It is a lot > better than mysql though. Is it? What kind of trigger does Postgres support that MySQL (5) doesn't? I didn't find any when I browsed through the trigger documentation for each. I might have overlooked some trigger which isn't currently supported by MySQL, but is by Postgres. I really don't like this repeated Postgres is better than MySQL bashing that is mostly based on long-outdated versions of MySQL. Both Postgres and MySQL are good database systems. However, each seems to have its own pro´s and con´s, and it all depends on what _you_ want to do with your database. For me, real-time replication is far more important than some obscure ACID things (Adam Skutt said MySQL had tons of things which can cause transaction invalidation, but honestly: transactions are there specifically to catch these invalidations instead of running headlong into an inconsistant database, and I actually never experienced a single transaction failure with MySQL). And even though Adam said MySQL would lack working row-locking, this has never failed for me. Subqueries have been supported since MySQL 4.1 and 5.0 also gives stored procedures and proper trigger support. So all in all: Check _your_ needs regarding database functionality (both on SQL level and on the database management level). After that, you can decide which DB-software is the best for _you_ (i.e. fullfills your requirements and is relatively cheap). There simply is no best database software (though there might be the worst somewhere). cu, sven
