[ale] Humor: MySQL vs. PostgreSQL

[Michael Trausch]

No... the problems will be elsewhere, then. But at least the data will be
consistent. And honestly, that's the most important part. No data would mean
no need for an application to process it.

--
Sent from my G2, an Android-powered mobile device.
On Oct 28, 2010 1:36 PM, "James Sumners" <james.sumners at gmail.com> wrote:
> The video was funny.
>
> I agree that people use, and design, software incorrectly. Changing
> the DB isn't going to fix that problem.
>
> *shrug*
>
> On Thu, Oct 28, 2010 at 1:23 PM, Michael B. Trausch <mike at trausch.us>
wrote:
>> 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
>
>
> --
> James Sumners
> http://james.roomfullofmirrors.com/
>
> "All governments suffer a recurring problem: Power attracts
> pathological personalities. It is not that power corrupts but that it
> is magnetic to the corruptible. Such people have a tendency to become
> drunk on violence, a condition to which they are quickly addicted."
>
> Missionaria Protectiva, Text QIV (decto)
> CH:D 59
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20101028/89eb30eb/attachment-0001.html