W dniu 2009-12-17 21:10, HillBilly pisze:
>
> "wloochacz" <w...@n...dgbit.spameromnie.pl> wrote in message
> news:hge1fj$6n9$1@inews.gazeta.pl...
> .
>>
>> IMO zamiast podstawowego klucza złożonego, lepiej zrobić sztyczny PK +
>> ograniczenie typu unique.
>> Co do kluczy naturalnych - czasem, ale to naprawdę czasami - jest
>> przydatny i to naprawdę zależy od tego co to za aplikacja i jakiego
>> rodzaju dane obrabia.
>> Znam pewien ERP, gdzie PK (i ID w app) jest tylko i wyłącznie kluczem
>> naturalnym - user musi wszystko wpisać z łapy (id towaru, id klienta,
>> id magazynu itd.). I to działa i nawet mi to nie przeszkadza :)
>>
>
>
> Raz się już przejechałem w życiu na naturalnym PK i w życiu tego błędu
> nie popełnię. Nawet jeśli w pierwszej fazie wydaje się to świetnym
> pomysłem, to potem odbija się to niezłą czkawką, szczególnie, gdy
> dochodzi do wszelkiej maści jego modyfikacji. Dlatego z urzędu polecam
> twór: automagiczny PK+ograniczenie unique na kolumnie, która mogłaby być
> PK. To samo tyczy się tabel z kluczem wielokolumnowym. Żadnych kluczy
> naturalnych.
E tam - bez przesady. Jeśli ma się do czynienia z bazą danych, która porządnie
obsługuje kaskadową aktualizację, to nie
ma żadnego problemu. Dobrym przykładem takiej bazy jest Firebird, złym - MS SQL w
dowolnej wersji.

--
wloochacz