Dlaczego warto używać wielu kolumn jako kluczy podstawowych (composite primary key)

Innym przykładem złożonych kluczy podstawowych jest użycie tabel asocjacyjnych. Załóżmy, że masz tabelę osób, która zawiera zestaw osób i tabelę grup, która zawiera zestaw grup. Teraz chcesz stworzyć wiele do wielu relacji na osobę i grupę. Oznacza to, że każda osoba może należeć do wielu grup. Oto jak wyglądałaby struktura tabeli przy użyciu złożonego klucza podstawowego.

Create Table Person(
PersonID int Not Null,
FirstName varchar(50),
LastName varchar(50),
Constraint PK_Person PRIMARY KEY (PersonID))

Create Table Group (
GroupId int Not Null,
GroupName varchar(50),
Constraint PK_Group PRIMARY KEY (GroupId))

Create Table GroupMember (
GroupId int Not Null,
PersonId int Not Null,
CONSTRAINT FK_GroupMember_Group FOREIGN KEY (GroupId) References Group(GroupId),
CONSTRAINT FK_GroupMember_Person FOREIGN KEY (PersonId) References Person(PersonId),
CONSTRAINT PK_GroupMember PRIMARY KEY (GroupId, PersonID))

Przykład W3Schools nie mówi, kiedy należy używać złożonych kluczy podstawowych, a podaje tylko przykładową składnię używając tej samej tabeli przykładowej, co dla innych kluczy.

Ich wybór przykładu może wprowadzić cię w błąd, łącząc bezsensowny klucz (P_Id) i klucz naturalny (LastName). Ten dziwny wybór klucza podstawowego mówi, że następujące wiersze są ważne zgodnie ze schematem i są niezbędne do jednoznacznej identyfikacji ucznia. Intuicyjnie nie czyni to sens.

1234     Jobs
1234     Gates

Czytaj dalej: wielka debata pierwszoplanowa lub po prostu Google meaningless primary keys lub nawet zapoznaj się z tym więc pytanie

FWIW-Moje 2 centy polega na unikaniu wielokolumnowych kluczy podstawowych i używaniu pojedynczego wygenerowanego pola id (klucz zastępczy) jako klucza podstawowego i dodawaniu dodatkowych (unikalnych) ograniczeń w razie potrzeby.

Tak, oba tworzą klucz główny. Szczególnie w tabelach, w których nie ma klucza zastępczego , może być konieczne podanie wielu atrybutów jako unikalnego identyfikatora dla każdego rekordu (zły przykład: tabela z imieniem i nazwiskiem może wymagać, aby ich kombinacja była unikalna).

Wiele kolumn w kluczu będzie ogólnie działać gorzej niż klucz zastępczy. Wolę mieć klucz zastępczy, a następnie unikalny indeks na kluczu wielokolumnowym. W ten sposób można uzyskać lepszą wydajność i zachować wyjątkowość potrzebną. Co więcej, gdy jedna z wartości w tym kluczu ulegnie zmianie, nie trzeba również aktualizować miliona pozycji potomnych w 215 tabelach potomnych.

Używasz klucza złożonego (klucza z więcej niż jednym atrybutem), gdy chcesz zapewnić wyjątkowość kombinacji kilku atrybutów. Pojedynczy klucz atrybutów nie osiągnie tego samego.

Twoje pytanie drugiej części

Ile kolumn można użyć razem jako klucza podstawowego w danej tabeli?

Jest specyficzny dla implementacji: jest zdefiniowany w aktualnie używanym DBMS.^[1],[2],[3] musisz sprawdzić specyfikację techniczną systemu baz danych, z którego korzystasz. Niektóre są bardzo szczegółowe, niektóre nie. Wyszukiwanie w Internecie takich ograniczeń może być trudne, ponieważ terminologia jest różna. Termin złożony klucz podstawowy powinien być wykonany obowiązkowe;)

Jeśli nie możesz znaleźć jednoznacznych informacji, spróbuj użyć testowej bazy danych, aby upewnić się, że możesz oczekiwać stabilnego (i konkretnego) postępowania z naruszeniem limitów (których można się spodziewać). Uważaj, aby uzyskać odpowiednie informacje na ten temat: czasami limity są gromadzone, a zobaczysz różne wyniki z różnymi układami baz danych.

• ^[1]SQL-Composite primary key limit? - Stos Overflow
• ^[2]SQL Server-Maksymalna liczba kolumn na klucz podstawowy
• ^[3]ile maksymalnej liczby kolumn może być częścią klucza podstawowego w tabeli w Oracle 9i i 10g?

Używanie klucza podstawowego w wielu tabelach jest przydatne, gdy używasz tabeli pośredniej w relacyjnej bazie danych.

Użyję bazy danych, którą kiedyś zrobiłem dla przykładu, a konkretnie trzech tabel w tej tabeli. Kilka lat temu stworzyłem bazę danych dla komiksu internetowego. Jedna tabela została nazwana "komiksami" -lista wszystkich komiksów, ich tytułów, nazwy plików graficznych itp. Głównym kluczem był "comicnum".

Druga tabela to "znaki" -ich nazwy i krótki opis. Na klucz główny był na "charname".

Ponieważ każdy komiks-z pewnymi wyjątkami-miał wiele postaci i każda postać pojawiła się w wielu komiksach, niepraktyczne było umieszczanie kolumny w "postaciach" lub "komiksach", aby to odzwierciedlić. Zamiast tego stworzyłem trzecią tabelę o nazwie "comicchars", która była listą postaci, w których pojawiły się komiksy. Ponieważ ta tabela zasadniczo połączyła dwie tabele, potrzebne były tylko dwie kolumny: charname i comicnum oraz klucz główny był na obu.