Re: Any *real* reason to choose a natural, composite PK over a surrogate, simple PK?
В списке pgsql-general по дате отправления:
| От | Tim Hart |
|---|---|
| Тема | Re: Any *real* reason to choose a natural, composite PK over a surrogate, simple PK? |
| Дата | |
| Msg-id | 49e3241216afc88683f9da8fa29d75e3@mac.com обсуждение |
| Ответ на | Re: Any *real* reason to choose a natural, composite PK over a surrogate, simple PK? (Trent Shipley <tshipley@deru.com>) |
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера