Re: FOREIGN KEYS vs PERFORMANCE

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>
Cc: PFC <lists(at)peufeu(dot)com>, Michael Glaesemann <grzm(at)myrealbox(dot)com>, Rodrigo Sakai <rodrigo(dot)sakai(at)zanthus(dot)com(dot)br>, pgsql-performance(at)postgresql(dot)org
Subject: Re: FOREIGN KEYS vs PERFORMANCE
Date: 2006-04-12 20:59:14
Message-ID: 20060412205914.GL49405@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Apr 12, 2006 at 10:36:28AM -0700, Craig A. James wrote:
> Jim C. Nasby wrote:
> >>1. You have only one application that modifies the data. (Otherwise, you
> >>have to duplicate the rules across many applications, leading to a
> >>code-maintenance nightmare).
> >
> >You forgot something:
> >
> >1a: You know that there will never, ever, ever, ever, be any other
> >application that wants to talk to the database.
> >
> >I know tons of people that get burned because they go with something
> >that's "good enough for now", and then regret that decision for years to
> >come.
>
> No, I don't agree with this. Too many people waste time designing for
> "what if..." scenarios that never happen. You don't want to be dumb and
> design something that locks out a foreseeable and likely future need, but
> referential integrity doesn't meet this criterion. There's nothing to keep
> you from changing from app-managed to database-managed referential
> integrity if your needs change.

In this case your argument makes no sense, because you will spend far
more time re-creating RI capability inside an application than if you
just use what the database offers natively.

It's certainly true that you don't want to over-engineer for no reason,
but many times choices are made to save a very small amount of time or
hassle up-front, and those choices become extremely painful later.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Luke Lonergan 2006-04-12 22:35:33 Re: bad performance on Solaris 10
Previous Message Jim C. Nasby 2006-04-12 20:44:22 Re: Better index stategy for many fields with few values