[ale] Humor: MySQL vs. PostgreSQL

[Lightner, Jeff]

That isn't just an issue for DBs.  I can't tell you the number of times I've had to beat developers into submission to fix their code that is eating system resources.   The usual suggestion I get is something like "double the current kernel parameter setting".   That particular suggestion is the one that always lets me know when someone has done absolutely no trouble shooting or research.   There are a few occasions where a new application or process does in fact require increasing limits to accommodate it but that is almost never "double the current setting".  

-----Original Message-----
From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of James Sumners
Sent: Thursday, October 28, 2010 1:36 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] Humor: MySQL vs. PostgreSQL

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
 
Proud partner. Susan G. Komen for the Cure.
 
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------