[ale] Humor: MySQL vs. PostgreSQL

[Michael B. Trausch]

On Thu, 2010-10-28 at 13:09 -0400, James Sumners wrote:
> PostgreSQL may be better, I haven't taken the time to check it out.
> But a video created less than 2 months ago should at least get the
> MySQL features correct. Before the first minute is over they say MySQL
> doesn't support "Transactions" or "foreign keys". Hmmm, [1] and [2]
> says otherwise. Oh, and they say MySQL isn't "ACID compliant." Here's
> a quote from [1]: "InnoDB [MySQL table type] provides full ACID
> compliance."
> 
> Anyway, back to watching the rest of the video. 

Ahh, that'd be why you got this the way you did.

While the InnoDB tables support those, they are still optional features.
You can disable them.

There are two major reasons that I started using PostgreSQL for my
personal and commercial projects some time back:

  * Referential integrity is absolutely rock-solid.  There is no way
    to disable it, no way to evade it, and this makes supporting apps
    that other people will eventually modify a great deal easier.

  * PostgreSQL's rich support for data types is second to none.  Well,
    maybe there is another database server that does it better, but if
    so, I am not aware of it.

Working on projects that use MySQL anymore causes me a great deal of
frustration---mostly because of the lack of types, but also because of
the great many inconsistent databases that I come across.  It is a huge
sign of suck when you come across an application that both uses a
database server that isn't configured to enforce referential integrity
and the application doesn't bother either, because then you have to do
things like write a fsck-like program that is specific to the
application's schema just to identify and attempt to resolve trouble.
This has been the cause of more grief than I can possibly enumerate.

Now, one can argue that a properly designed and a properly written
application will never encounter these issues, even if the application
is using flat files.  That would be an accurate assessment.
Unfortunately, many applications today don't do that.  They will go the
extra mile to ensure data integrity when they're using a home-cooked
format, usually.  But many people seem to think that just because
they're using a relational database server that those problems aren't
the job of the application to manage anymore.  That is certainly not the
case if one is using SQLite (not that anyone SHOULD be using that in a
production environment as anything other than a simple, mostly read-only
thing perhaps for a very specialized Web application) or an improperly
configured (or configured for "performance") instance of MySQL.

	--- Mike