Search Postgresql Archives

Re: Any *real* reason to choose a natural, composite PK over a surrogate, simple PK?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux