> From: Bill Schneider [mailto:[EMAIL PROTECTED]] > > Naveen: > > In general I prefer PostgreSQL to MySQL, but it depends on > what you're doing. > > > 1) Entire installation will be on Windows > > Licensing issues (cygwin reqmt for > > postgre...) > > I do think you need cygwin on Windows to run PostgreSQL (in > fact Cygwin comes with a pre-built postgresql) but I do not > know the licensing requirements for Cygwin.
Cygwin itself is GPL, but the required DLL is LGPL (I think). > > 2) Performance > > MySQL sometimes performs better, because it does less stuff. > (Weaker SQL support, no transactions by default.) >From what I understand, MySQL 4 has support for row level locking on transactions with the InnoDB tables. They do have a link to a CNet or ZDnet article (can't remember which) that showed MySQL keeping pace with Oracle. They were able to mix and match which tables allow transactions to help performance tuning (tables only required for lookup values don't need to have transactions). In absence of transactions, MySQL uses default values for any columns that require non-null values. BTW: the chief note from the article on MySQL vs. MS SQL Server, Oracle, Sybase, and I think one other is that the driver made all the difference in the world. The MS SQL Server driver from Microsoft sucked, and was not able to perform all the tests--although the C based ODBC driver rocked. Oracle had a good driver--although it has very flaky BLOB support. Sybase suffered from the driver caching too much information. After a certain amount of forwards and backwards scrolling through large resultsets the driver imploded. It is better for client applications, but not application servers. MySQL kept pace with Oracle--although I have not tried its BLOB support. Unfortunately, PostgreSQL was not tested in that article. It would really be interesting. I have not seen any current comparisons between MySQL and PostgreSQL. I would like to see an article comparing MySQL and PostgreSQL with their latest versions with transactions enabled. > > 4) Store 40MB of Blobs - inline/offline BFILE kind > > of support > > PostgreSQL has pretty spiffy large-object support. I don't > know about MySQL's. PostgreSQL has an OID type, similar to > Oracle LOB/CLOB, where you store just the object identifier > in the row and the actual object data gets stored somewhere > outside the table. They provide a set of stored procedures > (lo_...) that allow you to import/export content from the > filesystem, and I believe you can also create references to > offline objects in the filesystem like Oracle BFILEs (not > sure about this). > > The only catch is it doesn't work very well with Torque; > especially if you want your Java code to be db-independent. > When you do a "select oid_column from table" the PostgreSQL > JDBC driver will return to you a java.lang.Integer containing > the object ID number, not a java.sql.Blob. :/ Is there anyway that the DB mapping layer in Torque can compensate for that? > > 5) Transaction suport > > If transaction support is an absolute requirement, I'd go > with PostgreSQL over MySQL. MySQL hasn't even supported > transactions until somewhat recently and they're still > treated as somewhat of an optional add-on rather than a core feature. It's a cool concept to be able to mix and match table types to get performance benefits on tables that don't require transactions but still maintain safety on those that do require it. If we had an application that let you submit new products to a retailer (something my company did), the transaction references the category tables and demographic tables--but it doesn't update them. Therefore, the referenced tables can be optimized by not requiring transactions. > > > 7) Failover/Replication support > This is something you won't really get with a free db though > there might be a way to do it. Both MySQL and PostgreSQL have commercial arms. That might be worth the meager support fees to figure out how to do. The support fees are quite reasonable (compared to commercial companies that might charge you just to test their product). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
