Klucze złożone nigdy nie powinny być brane pod uwagę w „nowych” aplikacjach. Były używane w przeszłości przez ludzi, którzy uważali, że „klucze biznesowe” są lepsze niż „klucze zastępcze”.
Edycja:zgodnie z prośbą Chrisa rozszerzam swoją odpowiedź.
Zacznę od stwierdzenia, że rozumiem to pytanie jako „Klucze podstawowe złożone” i „Klucze zastępcze”.
Przyznaję też, że jest jeden przypadek użycia, w którym klucz złożony ma sens:w tabelach odniesień krzyżowych, zwanych również „tabelami łączy”. Są one używane w tabelach wiele do wielu i składają się tylko z dwóch pól, z których oba stanowią klucze obce, które tworzą klucz podstawowy tabeli odnośników. Na przykład UserRole tabela zawierałaby user_id i role_id , nic więcej. Na przykład w Javie nie ma reprezentacji klas dla takiej tabeli. Zwykle jest to @ManyToMany , z Collection po obu stronach.
Podzieliłem się moimi poglądami na temat kluczy naturalnych i kluczy zastępczych w innej odpowiedzi ( Hibernacja :Opinie w Composite PK vs Surrogate PK ) ) i uważam, że klucze kompozytowe mają pewne wady klucza naturalnego, ale nie przynoszą żadnych realnych korzyści.
Problem z kluczami złożonymi polega na tym, że potrzebujesz dwóch wartości, aby jednoznacznie zidentyfikować rekord. Staje się to problemem, gdy zaczniesz mieć tabele, które odwołują się do rekordów w tej pierwszej tabeli. Drugi stół potrzebuje wtedy dwóch kolumny, aby móc odwołać się do jednej nagrywać. A jeśli ta druga tabela używa klucza złożonego składającego się z jednej wartości + klucza obcego, teraz masz trzy kolumny do jednoznacznej identyfikacji jednej nagrywać. A trzeci stół wymagałby tych trzech dodatkowe kolumny tylko w celu odniesienia do jednej rekord w drugiej tabeli. Naprawdę, to jest śnieżna kula.
Inną wadą jest to, że wymagania do zmiana. Cały czas. Tak więc to, co dziś wydaje się być dobrym kluczem złożonym, jutro wcale nie będzie kluczem. Dlatego mamy klucze zastępcze:aby być przygotowanym na przyszłość.
Klucze złożone są używane głównie po to, aby rekordy w tabeli były unikatowe na podstawie zestawu kolumn. Na przykład, jeśli masz Customers tabeli, możesz mieć NationalId +Country jako unikalną wartość, co oznacza, że dwóch użytkowników nie może dzielić tego samego numeru SSN, jeśli ich krajem jest USA. Ale możliwe jest posiadanie tego samego numeru dla dwóch rekordów, jeśli nie znajdują się one w tym samym kraju. Jeśli lubisz klucze złożone, byłby to dobry kandydat do tego. Ale jak wspomniałem wcześniej, możesz użyć klucza zastępczego i zastosować unique ograniczenie. Zyskasz zalety klucza kompozytowego oraz bezpieczeństwo klucza zastępczego.
