- Co to są klucze?
- Proste klawisze
- Klucze połączone lub złożone
- Klucze główne
- Numeracja i automatyczne zwiększanie
- Czy tabela może zawierać wiele kluczy podstawowych?
Podczas gdy wielu programistów i administratorów baz danych może pracować z primary keys każdego dnia fascynującym tematem jest zadawanie sobie pytania:„Czym dokładnie jest primary key i może (lub powinna) tabela bazy danych zawierać wiele primary keys jednocześnie?”
Poniżej przeanalizujemy te pytania bardziej szczegółowo i spróbujemy dojść do rozsądnego i ogólnie uzgodnionego konsensusu w społeczności programistów.
Co to są klucze?
Aby zrozumieć, co to jest primary key znajduje się w tabeli bazy danych, musimy najpierw trochę zrozumieć non-primary keys . key w tabeli jest po prostu atrybutem używanym do identyfikowania i uzyskiwania dostępu do tych informacji. Tabela może i często będzie mieć wiele kluczy, na przykład w tabeli Users oba email i username mogą być uważane za klucze.
W zależności od programisty lub administratora, z którym rozmawiasz, możesz usłyszeć o różnych typach kluczy i ich definicjach, więc omówimy poniżej kilka różnych przykładów i podstawowe definicje każdego z nich.
Klawisze proste
simple key to tylko klucz używający tylko jednego atrybutu w tabeli. O ile nie nałożymy większych ograniczeń na klucz lub tabelę, to username atrybut w powyższym przykładzie to simple key .
Klucze połączone lub złożone
O krok dalej od simple keys są concatenated lub compound Klucze. Jak sama nazwa wskazuje, concatenated key jest połączeniem wielu single keys . Na przykład system może automatycznie łączyć last_name i year_of_birth single keys w concatenated key , na przykład:smith1980 .
Klucze podstawowe
[primary key](https://en.wikipedia.org/wiki/Unique_key) jest kluczem, który został wybrany jako główny (lub podstawowy ) reprezentatywny atrybut dla tego wiersza danych. primary key jest wyjątkowy i ten atrybut jest następnie używany w całej bazie danych i jest dostępny i przekazywany do innych tabel jako atrybut reprezentatywny dla danych, o których mowa.
W praktyce primary key atrybut jest również oznaczony jako NOT NULL w większości baz danych, co oznacza, że atrybut musi zawsze zawierać wartość, aby rekord został wstawiony do tabeli.
Na przykład email lub username simple keys mógł otrzymać oznaczenie primary key , ale zazwyczaj najlepszą praktyką jest ustawienie primary key do atrybutu, który nie jest (lub nie może) zostać zmieniony ani przez logikę biznesową, ani nawet przez osobę. Na przykład wyobraź sobie User otrzymuje nowy adres e-mail, co powoduje, że wszystkie przeszłe primary key skojarzenia utworzone przy użyciu starego adresu e-mail stają się nieważne podczas korzystania z nowego adresu e-mail.
Z tego powodu (między innymi) większość primary keys użyj numeru lub unikalnego ciągu, takiego jak [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) .
Numeracja i automatyczne zwiększanie
Warto również krótko zauważyć, że wiele systemów baz danych jest skonfigurowanych w taki sposób, że każda tabela ma primary key to jest zarówno numeryczne, jak i automatycznie zwiększane. Oznacza to po prostu, że sam silnik bazy danych automatycznie przypisuje każdemu nowemu rekordowi w tej tabeli unikalny primary key wartość, która jest przyrostowo większa niż wszystkie poprzednie wartości. Jednak większość programistów zgadza się, że ta praktyka jest nieaktualna i ujawnia niepotrzebne luki w zabezpieczeniach systemu, gdy jest używana przez niektóre tabele reprezentujące określone dane.
Na przykład wyobraź sobie wszystkie User rekordy otrzymują automatycznie zwiększany primary key wartość, znana jako id atrybut. Jeśli złośliwa osoba odkryje, że id atrybut danego użytkownika (np. Jan Kowalski) to wartość 1500 , to już ujawnia trochę informacji. Po pierwsze, wskazuje, że prawdopodobnie w systemie jest co najmniej 1499 innych użytkowników lub byli w pewnym momencie. Oznacza to również, że jeśli do strony użytkownika Johna Smitha można uzyskać dostęp za pośrednictwem adresu URL lub wywołania API, które zawiera ten id wartość 1500 , istnieje duża szansa, że po prostu zmienisz wartość na inną liczbę, na przykład 1499 lub 1501 , odsłoni stronę innego użytkownika, który może nie chcieć, aby ten użytkownik miał dostęp do jego strony. W ten sposób rekordy można przeszukiwać, po prostu zgadując id wartości w skali masowej.
Są to oczywiście bardzo proste przykłady, ale z tych powodów większość nowoczesnych baz danych będzie używać losowego i unikalnego primary key wartość atrybutu, taka jak UUID podczas pracy z danymi wrażliwymi.
Czy tabela może zawierać wiele kluczy podstawowych?
Krótka odpowiedź to nie , tabela nie może zawierać wielu primary keys , ponieważ jest to sprzeczne z podstawowymi zasadami projektowania relacyjnych baz danych (patrz:[database normalisation](https://en.wikipedia.org/wiki/Database_normalisation) i [Third normal form](https://en.wikipedia.org/wiki/Third_normal_form) ).
To jest możliwe, że tabela może mieć wiele candidate keys , które skutecznie zachowują się podobnie do primary key w tym candidate key jest unikalny, NOT NULL i jest pojedynczą reprezentacją tego rekordu tabeli.
Jednak jeśli chodzi o wybór jednego atrybut zostanie przypisany jako primary key dla tabeli wybór pochodzi z listy wszystkich potencjalnych candidate keys (stąd nazwa, są kandydatami do stania się primary key ). Ostatecznie tylko jeden candidate key jest wybrany jako najlepszy reprezentatywny atrybut dla tego rekordu, który ma być używany w tej tabeli jako primary key i odwołuje się w innym miejscu w bazie danych przez inne tabele poprzez ich odpowiednie foreign keys .
