Re: CMS, foreign keys, and the legacy of MySQL - Mailing list pgsql-advocacy

From Christophe Pettus
Subject Re: CMS, foreign keys, and the legacy of MySQL
Date
Msg-id E41476AB-6BC4-4CBE-BCA6-288E6D4F83AD@thebuild.com
Whole thread Raw
In response to CMS, foreign keys, and the legacy of MySQL  (jj ff <m9mq@live.com>)
List 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
referentialintegrity, 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
anunreasonable entailment of that philosophy: The DB just stores stuff and returns it, and the application is the one
thatcares about the semantics of the data.  The logical conclusion of this is a schemaless database (CouchDB, etc.),
sinceit'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
problemsbecause the enforcement is distributed across tons of application code, the use of having data integrity in the
databasebecomes obvious.  Sadly, it usually requires something bad happening first, though. 

--
-- Christophe Pettus
   xof@thebuild.com


pgsql-advocacy by date:

Previous
From: Rob Wultsch
Date:
Subject: Re: CMS, foreign keys, and the legacy of MySQL
Next
From: Jeff
Date:
Subject: Reddit's latest failure & PG