Re: FOREIGN KEYS vs PERFORMANCE

From: "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: FOREIGN KEYS vs PERFORMANCE
Date: 2006-04-13 01:32:39
Message-ID: 443DAA37.80902@modgraph-usa.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jignesh K. Shah 2006-04-13 01:53:33 Re: bad performance on Solaris 10
Previous Message patrick keshishian 2006-04-13 01:26:10 pg 7.4.x - pg_restore impossibly slow