Dlaczego warto używać wielu kolumn jako kluczy podstawowych (złożony klucz podstawowy)

109

Ten przykład pochodzi z w3schools .

CREATE TABLE Persons
(
    P_Id int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255),
    CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
)

Rozumiem, że obie kolumny razem ( P_Idi LastName) reprezentują klucz podstawowy tabeli Persons. Czy to jest poprawne?

Dlaczego ktoś miałby chcieć użyć wielu kolumn jako kluczy podstawowych zamiast jednej kolumny?
Ile kolumn może być używanych razem jako klucz podstawowy w danej tabeli?

— rockbala
źródło

... teraz jest też odpowiedź na drugie pytanie

— Wolf

1

@Martijn Peters. Dlaczego odpowiedź została usunięta?

— PerformanceDBA

119

Twoje rozumienie jest prawidłowe.

Zrobiłbyś to w wielu przypadkach. Jednym z przykładów jest związek taki jak OrderHeaderi OrderDetail. PK OrderHeadermoże być OrderNumber. PK in OrderDetailmoże być OrderNumberAND LineNumber. Gdyby to był którykolwiek z tych dwóch, nie byłby wyjątkowy, ale połączenie tych dwóch gwarantuje niepowtarzalność.

Alternatywą jest użycie wygenerowanego (nieinteligentnego) klucza podstawowego, na przykład w tym przypadku OrderDetailId. Ale wtedy nie zawsze łatwo dostrzegasz związek. Niektórzy wolą jeden sposób; niektórzy wolą inną drogę.

— MJB
źródło

2

Czy jest to przydatne, jeśli używam branch_id i używając replikacji między dwiema bazami danych, rozwiąże problem duplikatów identyfikatorów? !!

— Mhmd

11

Zwróć uwagę, że w wielu przypadkach używania wygenerowanego klucza podstawowego często nadal potrzebujesz unikalnego klucza dla wartości złożonych.

— Bacon Bits

Proszę rozwinąć temat „Niektórzy ludzie wolą jeden sposób; niektórzy wolą inny sposób”.

— Nazwa użytkownika

1

Prośby rozwinięte? Nie wiem, co powiedzieć. Znam ludzi, którzy wolą mieć wiele połączonych pól jako klucz, ponieważ łatwiej jest intuicyjnie zrozumieć, na co patrzą. Znam inne osoby, które wolą po prostu przypisać unikalny klucz do każdego wiersza, ponieważ wpisywanie jest łatwiejsze i szybsze. Czy o to pytasz?

— MJB

Ta wiadomość była przeznaczona dla @Username. Zapomniałem o tym reżyserować.

— MJB

26

Innym przykładem złożonych kluczy podstawowych są tabele asocjacji. Załóżmy, że masz tabelę osób zawierającą zestaw osób i tabelę grupową zawierającą zestaw grup. Teraz chcesz stworzyć relację wiele do wielu 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))

— John Hartsock
źródło

świetne wyjaśnienie: myślę, że kluczem jest potrzeba atrybutów relacji m-do-n (w znormalizowanej fasadzie).

— Wolf

może dodać trochę wyjaśnienia korzyści, byłoby jeszcze lepsze

— Marsjan2049

10

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

Ich przykład może wprowadzać w błąd, łącząc bezsensowny klucz (P_Id) i naturalny klucz (LastName). Ten dziwny wybór klucza podstawowego mówi, że następujące wiersze są prawidłowe zgodnie ze schematem i są niezbędne do jednoznacznej identyfikacji ucznia. Intuicyjnie nie ma to sensu.

1234     Jobs
1234     Gates

Dalsza lektura: Wielka debata na temat klucza podstawowego lub po prostu Google, meaningless primary keysa nawet przeczytaj to pytanie SO

FWIW - Moje 2 centy to unikanie wielokolumnowych kluczy podstawowych i używanie pojedynczego wygenerowanego pola identyfikatora (klucza zastępczego) jako klucza podstawowego i dodawanie dodatkowych (unikalnych) ograniczeń w razie potrzeby.

— Robert Paulson
źródło

1

1) link „świetna debata na temat klucza podstawowego” jest szczególnie głupi, informacje są fałszywe i służą same sobie. 2) Nie można uniknąć indeksu kolumn, które sprawiają, że wiersz jest unikalny. Identyfikator zastępczy z indeksem jest zawsze dodatkową kolumną i dodatkowym indeksem. Raczej głupie, ponieważ jest zbędne. I wolniej.

— PerformanceDBA

2

„Wielka debata na temat klucza podstawowego” nie jest głupia. Jest to bardzo ważny problem ze strony programistów, którzy nie są programistami sql ani DBA sql i nie spędzają całego czasu w sql. Nawet w czystym sql wolałbym mieć bezsensowny automatycznie generowany klucz jako klucz podstawowy podczas łączenia, niż pamiętać o przekazywaniu n bitów danych jako klucza naturalnego. Zapraszamy do swojego punktu widzenia, ale bylibyśmy wdzięczni za nie lekceważenie.

— Robert Paulson

4

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

— nvogel
źródło

1

Jeśli chodzi o zapewnienie unikalnego klucza, możesz polegać na kombinacji dwóch atrybutów w celu utworzenia klucza, którego logicznie nie można powielić, przykładem może być osoba i data ukończenia z większego zbioru danych.

— John Mark

3

Tak, oba tworzą klucz podstawowy. Szczególnie w tabelach, w których nie masz klucza zastępczego , może być konieczne określenie wielu atrybutów jako unikalnego identyfikatora dla każdego rekordu (zły przykład: tabela zawierająca zarówno imię, jak i nazwisko może wymagać, aby ich kombinacja była wyjątkowy).

— ig0774
źródło

3

Wiele kolumn w kluczu będzie generalnie działać gorzej niż klucz zastępczy. Wolę mieć zastępczy klucz, a następnie unikalny indeks klucza wielokolumnowego. W ten sposób można uzyskać lepszą wydajność i zachować wymaganą wyjątkowość. A nawet lepiej, gdy zmienia się jedna z wartości w tym kluczu, nie trzeba również aktualizować miliona wpisów podrzędnych w 215 tabelach podrzędnych.

— HLGEM
źródło

1

1) Wydajność. Nie na platformie SQL (może w udawanych "sql" i freeware). 2) Preferencje nie mają znaczenia. Istotne jest to, czego wymagają tabele dla integralności. 3) Identyfikator zastępczy z indeksem jest zawsze dodatkową kolumną i dodatkowym indeksem. To byłoby wolniejsze na każdej platformie. Re performance, zaprzeczasz sobie. 4) Jeśli nie wiesz, jak poprawnie zaktualizować mityczne „milion wpisów podrzędnych w 215 tabelach podrzędnych” , zadaj pytanie.

— PerformanceDBA

2

Nie zgadzam się ze stwierdzeniem „Wiele kolumn w kluczu generalnie będzie działać gorzej niż klucz zastępczy”. Często wymagane jest dodatkowe zapytanie, aby uzyskać zastępczy klucz relacji, gdy ją rozważasz. W tym momencie jest to pełna, dodatkowa podróż w obie strony, wolniejsza pod względem wydajności.

— ttugates

3

Twoje drugie pytanie

Ile kolumn może być używanych razem jako klucz podstawowy w danej tabeli?

jest specyficzne dla implementacji: jest zdefiniowane w aktualnie używanym DBMS. ^{[1], [2], [3]} Musisz zapoznać się ze specyfikacją techniczną używanego systemu bazodanowego. Niektóre są bardzo szczegółowe, inne nie. Przeszukiwanie sieci pod kątem takich ograniczeń może być trudne, ponieważ terminologia jest różna. Termin złożony klucz podstawowy powinien być obowiązkowy;)

Jeśli nie możesz znaleźć jednoznacznych informacji, spróbuj utworzyć testową bazę danych, aby upewnić się, że możesz oczekiwać stabilnej (i konkretnej) obsługi naruszeń limitów (których należy się spodziewać). Uważaj, aby uzyskać właściwe informacje na ten temat: czasami limity się kumulują i zobaczysz różne wyniki przy różnych układach bazy danych.

— Wilk
źródło

2

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

Jako przykład użyję bazy danych, którą kiedyś stworzyłem, a konkretnie trzech tabel w tej tabeli. Kilka lat temu stworzyłem bazę danych dla komiksu internetowego. Jedna tabela nosiła nazwę „komiksy” - lista wszystkich komiksów, ich tytuły, nazwy plików graficznych itp. Kluczem podstawowym było „comicnum”.

Druga tabela zawierała „znaki” - ich imiona i krótki opis. Klucz podstawowy znajdował się na „charname”.

Ponieważ każdy komiks - z pewnymi wyjątkami - miał wiele postaci, a każda postać pojawiała się w wielu komiksach, niepraktyczne było umieszczanie kolumny w „postaciach” lub „komiksach”, aby to odzwierciedlić. Zamiast tego stworzyłem trzecią tabelę nazwaną „komiksy” i była to lista postaci, w których komiksy pojawiały się. Ponieważ ta tabela zasadniczo łączyła dwie tabele, potrzebowała tylko dwóch kolumn: nazwa_znaku i liczba_znaków, a klucz podstawowy znajdował się w obu.

— Mr. Initial Man
źródło

1

Tworzymy złożone klucze podstawowe, aby zagwarantować niepowtarzalność wartości kolumn, które składają się na pojedynczy rekord. Jest to ograniczenie, które pomaga zapobiegać wstawianiu danych, których nie należy powielać.

tj .: jeśli wszystkie identyfikatory uczniów i numery aktów urodzenia są jednoznacznie przypisane do jednej osoby. W takim razie dobrym pomysłem byłoby utworzenie klucza podstawowego dla osoby w postaci numeru identyfikacyjnego ucznia i numeru aktu urodzenia, ponieważ zapobiegnie to przypadkowemu wstawieniu dwóch osób, które mają różne identyfikatory studentów i ten sam akt urodzenia.

— kiwicomb123
źródło