Wielokrotnie używałem kluczy naturalnych (kompozytowych) jako PK i nigdy nie miałem z tym kłopotu. Tyle, że to był mój, zaplanowany wybór, a nie sytuacja, gdy ktoś czegoś nie przewidział i tak wyszło.
Wielokrotnie używałem kluczy naturalnych (nie kompozytowych) i zawsze prędzej czy później stanowiło to problem.
Ale jest wygodne przy testowaniu i pisaniu zapytań z palca - to bezsprzecznie prawda.
Będąc młodym adeptem uczyłem się takich bzdur od ludzi odpowiedzialnych za rozwój i wdrożenie bardzo dużych systemów klasy światowej (w roku 1998 system z USA oparty o MSSQL działający natywnie na Windows i Apple, to był kosmos). Kiedy ja zaczynałem pracę w branży, nie było czegoś takiego jak senior albo mentor. Do wszystkiego trzeba było dojść samemu i to często bez internetu. A więc jak już spotkałeś kogoś, kto wiedział więcej niż przeciętnie, to patrzyło się na niego jak na bóstwo... Miałem szczęście (mieszkając na głębokiej prowincji to jak 6 w totka), znałem dwóch takich gości :)
Klucz kompozytowy to w ogóle porażka, kiedy dana tabela jest w relacji do innej.
Łączenie po 5 polach?
Aby odświeżyć jeden rekord, trzeba mieć wartości wszystkich 5 pól, a nie jednego ID - to nie ma być kłopot?
Wszystko zależy od konkretnej architektury, odwołań z innych tabel i potencjalnego rozwoju / zmiany struktury danych w przyszłości.
Wszystko prawda, ale...
Będąc już doświadczonym (nawet bardzo, bardzo doświadczonym) adeptem zaprojektowałem bazę danych do własnego systemu. Byłem i jestem również ekspertem dziedzinowym. A więc naprawdę byłem absolutnie przekonany, że w momencie jak mnie tknęło "tu zrobimy klucz naturalny" będzie wszystko OK. Bo przecież wiem co robię, wiem jak to się będzie rozwijać i wiem komu i do czego będzie to potrzebne.
No i było super... przez 3 lata, a potem przyszła konieczność modyfikacji wartości tego klucza naturalnego.
Niby nie kłopot, ale ta tabela to jedna z głównych tabel całego systemu, a więc ma sporo zależności po kluczu głównym.
A że w MSSQL kaskadowa aktualizacja kuleje (do dziś może być tylko jedna ścieżka dojścia dla FK - to jest naprawdę słabe ale nauczyłem się z tym żyć), to nie było trywialne zadanie.
Poza tym co napisał Patryk27, że czasami jest tak wygodniej, to jeśli miałbyś zmieniać system tylko po to, by dodać klucz zastępczy (surrogate), bo kiedyś może Ci się przyda, a obecnie nie masz z tym problemów, to ja bym poczekał, aż to może kiedyś stanie się bardzo realne i wtedy dokonał zmiany.
Ja bym na nic nie czekał, tylko włożył tam klucz sztuczny i finito.
To nie jest przedwczesna optymalizacja, tylko dobra praktyka.
Po prostu.
Dodam jeszcze, że mam podobny mechanizm (dane zaciągane z obcego systemu ERP) i w takim przypadku zawsze wkładam jeszcze jedno pole do takich tabel/widoków - ID wiersza z obcego systemu. Wielokrotnie się przekonałem, że posiadanie takiej wartości jest pomijalne z punktu widzenia utrzymania w systemie, a znakomicie otwiera możliwości do dalszych (w razie potrzeby) fikuśnych modeli przetwarzania danych z systemu ERP.
Bo po prostu mam ID z ERP.