Re: Any *real* reason to choose a natural, composite PK over a surrogate, simple PK? - Mailing list pgsql-general

From Tim Hart
Subject Re: Any *real* reason to choose a natural, composite PK over a surrogate, simple PK?
Date
Msg-id 49e3241216afc88683f9da8fa29d75e3@mac.com
Whole thread Raw
In response to Re: Any *real* reason to choose a natural, composite PK over a surrogate, simple PK?  (Trent Shipley <tshipley@deru.com>)
List pgsql-general
While this statement is accurate, it isn't very precise. Needs change.
Requirements change. Usage changes. Any one of these changes can
invalidate a very correct initial analysis. A wise designer anticipates
change to minimize impact on both current work *and* future development
effort. Artificial keys are a very simple and effective guard against
human assumption and protect future design robustness.

Tim

On Jun 8, 2006, at 7:59 PM, Trent Shipley wrote:

> Likewise, the stability provided by a surrogate key is arguably
> illusory.  If
> N is the primary key and the values in composite key ABC change then
> the
> surrogate key N simply masks poor design.  If ABC is not stable then
> the
> initial analysis was flawed and ABC was not a valid candidate for a
> primary
> key.
>
> N only provides stability if the contents of ABC change in such a way
> that ABC
> remains unique.


pgsql-general by date:

Previous
From: "Qingqing Zhou"
Date:
Subject: Re: error 57014
Next
From: "Harald Armin Massa"
Date:
Subject: Re: Out of Memory Error on Postgresql 8.1.3. on win32