Re: CMS, foreign keys, and the legacy of MySQL

From: Christophe Pettus <xof(at)thebuild(dot)com>
To: PostgreSQL Advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: CMS, foreign keys, and the legacy of MySQL
Date: 2011-03-18 05:56:08
Message-ID: E41476AB-6BC4-4CBE-BCA6-288E6D4F83AD@thebuild.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy


On Mar 17, 2011, at 11:52 AM, jj ff wrote:

> "The problem isn't that InnoDB itself is slow, it's that enforcing foreign key relations is slow. I'm a big fan of referential integrity, but in a CMS it's place is in the application layer, not the data layer." Why would anyone say that?

If you view the DB as just a way of getting the application's data onto disk and off of it, then the quotation is not an unreasonable entailment of that philosophy: The DB just stores stuff and returns it, and the application is the one that cares about the semantics of the data. The logical conclusion of this is a schemaless database (CouchDB, etc.), since it's all just blobs of application data.

Given that (at a guess) 90% of web startups are staffed by relatively junior application programmers with no DB background, and the natural tendency of very smart people to assume that which they do not understand isn't very important, and there you are.

Of course, as the application grows, and the number of different clients of the data grow, and you start getting data problems because the enforcement is distributed across tons of application code, the use of having data integrity in the database becomes obvious. Sadly, it usually requires something bad happening first, though.

--
-- Christophe Pettus
xof(at)thebuild(dot)com

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Jeff 2011-03-18 13:34:40 Reddit's latest failure & PG
Previous Message Rob Wultsch 2011-03-18 05:47:13 Re: CMS, foreign keys, and the legacy of MySQL