Skip site navigation (1) Skip section navigation (2)

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

From: Rob Wultsch <wultsch(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: jj ff <m9mq(at)live(dot)com>, pgsql-advocacy(at)postgresql(dot)org
Subject: Re: CMS, foreign keys, and the legacy of MySQL
Date: 2011-03-18 05:47:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacy
On Thu, Mar 17, 2011 at 11:59 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 3/17/11 11:52 AM, jj ff wrote:
>> Here's a comment I found while googling around on these issues:  "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?  What's the point of using a DB if you're not
>> doing to put FKs in it?
> Well, they're right ... for InnoDB.  If you're only experience with a
> relational database is MySQL, then you're liable to think that FKs are a
> disaster.
> --
>                                  -- Josh Berkus
>                                     PostgreSQL Experts Inc.

There are specific needs for doing things in unorthodox manners. If
the company is surviving by a thread and pulling fk means that the
company does not need to buy a new db server... yeah it may make
sense. Or if you operate in an environment where doing the check in
software is slightly more efficient and slightly more efficient means
saving a truckload of cash.

But yeah, most of the time fk's don't exist are because of ignorance
or lazy ignorance. Don't blame MySQL or InnoDB, they are pretty
awesome for a large set of possible problems.

If in doubt, blame a developer. <- You can quote me on that.

Rob Wultsch

In response to

pgsql-advocacy by date

Next:From: Christophe PettusDate: 2011-03-18 05:56:08
Subject: Re: CMS, foreign keys, and the legacy of MySQL
Previous:From: damien clochardDate: 2011-03-17 20:20:46
Subject: Re: Proposal for a PostgreSQL Print Magazine

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group