Re: Separate PK in Jxn Tbl?
Date: Mon, 28 Jan 2008 17:24:36 GMT
Message-ID: <odonj.910$R84.571_at_newssvr25.news.prodigy.net>
"David Cressey" <cressey73_at_verizon.net> wrote in message
news:%9lnj.5893$cm6.4751_at_trndny05...
>
> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
> wrote in message news:uzBiNoRYIHA.4172_at_TK2MSFTNGP02.phx.gbl...
>
>> This is the big problem with natural keys. When the theory was first
>> elaborated, the point was that a natural key never change its value.
>> That
>> was the point that was making the choice of a natural key on par with the
>> use of a surrogate key as the primary key of a table. However, like
> anyone
>> have discovered with experience, a natural key can change its value under
> a
>> set of various circonstances. One could argue that if a key can change
> its
>> value, than it's not a natural key but as you know, this argument bring
>> nothing in regard to help you choosing a natural key.
>>
>
> This is a specific example of a syndrome that I described more generally:
> the mismanagement of natural keys.
>
> If a key is "natural", it is managed, if at all, beyond the scope of the
> DBMS. It might be managed at the application layer, or it might be
> managed
> by people, or it might indeed be unmanaged data, like sunspots.
>
> When it is managed by other people, it is subject to mismanagement.
> Changing values that ought to be immutable is one of many ways that
> natural
> keys can be mismanaged.
>
> As I said before, I prefer to use natural keys where ever possible. If
> that's not possible due to mismanagement of the natural keys, I'll use
> synthetic keys.
>
>
>