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
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 |