Message-ID: <443DAA37.80902@modgraph-usa.com>
Date: Wed, 12 Apr 2006 18:32:39 -0700
From: "Craig A. James" <cjames@modgraph-usa.com>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
MIME-Version: 1.0
To: "Jim C. Nasby" <jnasby@pervasive.com>, pgsql-performance@postgresql.org
Subject: Re: FOREIGN KEYS  vs  PERFORMANCE
References: <001301c65d9c$08884ef0$4700a8c0@TREEZANTHUS>
	<72C39159-1A4B-4595-A978-1DF57AD42527@myrealbox.com>
	<op.s7vv4ex2cigqcu@apollo13> <443D127D.2070601@modgraph-usa.com>
	<20060412153951.GH49405@pervasive.com>
	<443D3A9C.40106@modgraph-usa.com>
	<20060412205914.GL49405@pervasive.com>
In-Reply-To: <20060412205914.GL49405@pervasive.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jim C. Nasby wrote:
>>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.

But one of the specific conditions in my original response was, "You have application-specific knowledge about when you can skip referential integrity and thereby greatly improve performance."  If you can't do that, I agree with you.

Anyway, this discussion is probably going on too long, and I'm partly to blame.  I think we all agree that in almost all situations, using the database to do referential integrity is the right choice, and that you should only violate this rule if you have a really, really good reason, and you've thought out the implications carefully, and you know you may have to pay a steep price later if your requirements change.

Craig