wloochacz pisze:
> 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.
>
Mógłbyś napisać co jest złego w kaskadowej aktualizacji w MSSQL?

Pozdrawiam

--
gregorius
Odpowiadając usuń spamerom_nie. z adresu.