High-performance builds of mysql are still faster. And with 5.4 integrating a lot of performance boosts, I'd expect MySQL to retain that lead for a lot longer. There's also a lot more guides / support for MySQL around, as well as having a more robust choosing of UDF's, if you were to need them. PostgreSQL is a great RDBMS, on the other hand, if you're a purist. It's more close to the SQL standards and has a different featureset. While MySQL-unique features are designed to help "normal people" with complex things - GROUP_CONCAT, for example - PostgreSQL-unique features are designed for complicated tasks handled by well-qualified people (custom data types, arrays, etc). Common knowledge is that MySQL lacks a lot of integrity features, but this isn't (as) true any more, with the introduction of foreign keys and constraints in InnoDB. Regarding storage engines, just use InnoDB by default and forget about it; in the rare cases where a different engine is better suited, you can change it later. The way I'd suggest is that if you're either willing to learn a lot of SQL or have already learned it in a class or something, go with postgres. If you just want to get it done (or care a lot about performance), go with MySQL. On Tue, Jun 2, 2009 at 9:25 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx>wrote: > On Tue, Jun 02, 2009 at 04:36:28PM -0400, optomatic@xxxxxxxxxx wrote: > > > Everybody has given Angus really great advice in this previous thread > > and I have learned a lot too. I hope no one mines the fork but I am in > > the exact same situation as Angus. If anyone could spare a bit of time > > regarding application infrastructure I would really appreciate it. > > > > I know there are lots of databases out there and PostgreSQL is held in > > high regard but the overwhelming majority of examples seem to use MySQL. > > Considering that Oracle has bought Sun, do you think it is still wise to > > use it for new applications? Oracle does not have much "street cred" in > > open source circles, maybe they'll cause trouble later and MySQL was > > already forking was it not? I'd like to use the same DB for a few years. > > > > I am attracted to building an application from scratch but I will never > > get an object relational mapper to work without a framework. If I go the > > scratch route, I'd better get my database done right(as was advised in > > the previous thread!)and getting that right probably starts with > > choosing the right DB. > > First, you don't need an ORM. I'll leave it at that. > > Second, if you're doing something which will be supported on internal > servers, choose PostgreSQL. MySQL has deficiencies caused by its > development by programmers. PostgreSQL was developed by DBAs. And > frankly, the choice of storage engines in MySQL is crazy. Some are > incapable of handling transactions, for example. You have to do research > and figure out which one has the features you need. Another random > example of MySQL deficiency is that it does not natively support boolean > fields. And at least some of the engines don't support foreign keys, > IIRC. > > MySQL has the popularity it does because 1) it has a *company* behind > it, which PostgreSQL does not; 2) it is relatively easy to administer; > 3) at one time it was faster than PostreSQL; 4) inertia/momentum. > > As for Oracle/Sun/MySQL, because MySQL is open source, there are already > forks of it. If Sun decides to get pissy, a new version of MySQL can be > cobbled together by the open source community in short order. No one > knows what Oracle will do with MySQL, ultimately, but I wouldn't let it > worry you too much. > > Your choice of DB won't really matter that much. Any database should do > pretty much whatever you ask of it. You can't actually go wrong with any > database. Your choice of database will mostly affect two things: 1) how > much work you have to do that the database won't do for you, and 2) > expense. > > Paul > > -- > Paul M. Foster > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
