Czy klucz podstawowy powinien być niezmienny?

26

Ostatnie pytanie na stackoverflow wywołał dyskusję o niezmienności kluczy podstawowych. Myślałem, że to taka zasada, że ​​klucze podstawowe powinny być niezmienne. Jeśli istnieje szansa, że ​​któregoś dnia klucz podstawowy zostanie zaktualizowany, pomyślałem, że powinieneś użyć klucza zastępczego. Jednak nie ma go w standardzie SQL, a niektóre funkcje „aktualizacji kaskadowej” RDBMS pozwalają na zmianę klucza podstawowego.

Więc moje pytanie brzmi: czy nadal jest to zła praktyka, aby mieć klucz podstawowy, który może się zmienić? Jakie są wady, jeśli w ogóle, posiadania zmiennego klucza podstawowego?

Vincent Malgrat
źródło

Odpowiedzi:

25

Tylko trzeba klucz podstawowy być niezmienna, jeśli jest połączony z klucza obcego, lub jeśli jest używany jako identyfikator zewnętrznej bazy danych (na przykład w wskazując URL do strony dla danego elementu).

Z drugiej strony musisz mieć zmienny klucz tylko wtedy, gdy zawiera on pewne informacje, które mogą ulec zmianie. Zawsze używam klucza zastępczego, jeśli rekord nie ma prostego, niezmiennego identyfikatora, którego można użyć jako klucza.

Guffa
źródło
7
Dlaczego „ potrzebujesz klucza podstawowego, aby był niezmienny, jeśli jest powiązany z kluczem obcym”? Jak wspomniano PO, większość RDBMS ma funkcję aktualizacji „kaskadowej”.
Thanatos,
1
@Thanatos większość (w rzeczywistości wszystko, co spotkałem) rdbms nie zezwala na modyfikowalne klucze podstawowe, ale mają aktualizacje kaskadowe. Klucz podstawowy, w ogólnie przyjętej mądrości dba, nie powinien zawierać żadnych informacji, powinien być jedynie unikalnym identyfikatorem rekordu (a więc nawet datownika, odroczonego zakresu rekordu itp.).
jwenting
5
@jwenting: Czy mówimy o tym samym? „większość rdbms nie zezwala na zmienne klucze podstawowe” obejmuje co? Zarówno MySQL, jak i PostgreSQL zezwalają na zmienne klucze podstawowe i honorują kaskadowe aktualizacje… tak, jak myślę, że standardowy SQL mówi, że powinny. Także „ogólnie przyjęta mądrość dba”? Spotkałem wielu DBA, którzy opowiadają się przeciwko kluczom zastępczym, i wielu, którzy opowiadają się przeciwko kluczom naturalnym.
Thanatos,
2
@Thanatos Argumenty na rzecz „wszystkie tabele muszą mieć odpowiedniki” nie zawierają odniesień bibliograficznych, cytują „ogólnie przyjętą mądrość dba”, ale nigdy nie cytują książki. Książki kanoniczne mówią, że powinieneś używać surogatu, jeśli: A. nie istnieje żaden naturalny klucz, B. klucz wielokolumnowy wykracza poza 3 kolumny lub C. Będziesz cały czas zmieniał klucz. Zatem: naturalne, gdy pasują, zastępuje, gdy naturalne nie pasują.
Tulains Córdova
4
@ user61852: Co?
Guffa
15

Klucz podstawowy powinien składać się z krotek niezbędnych do ustalenia wyjątkowości. Nie ma znaczenia, czy dane mogą ulec zmianie, czy nie. Liczy się tylko wyjątkowość zapisu. Taki jest projekt koncepcyjny bazy danych.

Kiedy wchodzimy w sferę implementacji, najbezpieczniej jest po prostu użyć klucza zastępczego.

Chris Holmes
źródło
15

Tak, moim zdaniem klucz podstawowy powinien być niezmienny.

Nawet jeśli istnieją oczywiste klucze kandydujące, zawsze używam klucza zastępczego. W kilku przypadkach nie zrobiłem tego i prawie zawsze tego żałowałem. I bez względu na to, jak niezmienny Twoim zdaniem jest klucz, nie możesz zabezpieczyć się przed błędami wprowadzania danych - mówiąc użytkownikom, że nie mogą edytować tej części informacji, ponieważ to klucz podstawowy nie myje się smutno.

richeym
źródło
Dobra uwaga na temat błędów wprowadzania danych
Tim Goodman
Richeym, wydaje się, że robisz przypadek, dlaczego klucze NIE mogą być niezmienne: użytkownicy mogą chcieć je zmienić.
nvogel
4
@dportas - chodzi mi o to, że lubię PK jako niezmienne, więc zawsze używaj kluczy zastępczych, nawet jeśli myślę, że istnieje oczywisty klucz, który można uzyskać z danych tabeli (np. e-mail, nazwa użytkownika).
richeym
2

Mechanizmy buforowania między bazą danych a użytkownikiem stracą skuteczność w przypadku zmiany kluczy podstawowych.

spoulson
źródło
2

Dlaczego nie? Ponieważ chcesz wyeliminować kolumnę?

To, że wymagania wymagają, aby trzy kolumny były unikalne, nie oznacza, że ​​musi to być klucz podstawowy. Możesz pomyśleć, że ta reguła będzie obowiązywać wiecznie (pamiętasz podczas tego spotkania, kiedy kierownik działu pinhead przysięgał, że to się nigdy nie zmieni? Wiesz, ten, który właśnie został zwolniony.), Ale tak się nie stanie.

Nie otrzymuję zapłaty za każdą aktualizację kaskadową, którą wdrażam, i premię, jeśli sami ją koduję.

Komputer nie wymaga żadnego znaczenia dla klucza; IMHO, klucze są dla komputerów, pozwól ludziom zepsuć resztę danych.

JeffO
źródło
1
„klucze są do komputerów, niech ludzie spieprzą resztę danych”. +1, miło.
2

Posiadanie klucza, którego wartości mogą ulec zmianie, nie jest złą praktyką.

Właściwości dobrego klucza obejmują stabilność. Niezmienność jest idealna, ale nie jest warunkiem wstępnym. Wprowadzenie sztucznego klucza ze względu na niezmienność jest złą praktyką.

Weźmy przykład międzynarodowego standardowego numeru książki (ISBN) . Jest bardzo stabilny, ale niezmienny: czasami wydawcy książek popełniają błędy i - horror! - mogą wystąpić zduplikowane numery ISBN. Czy to oznacza, że ​​ISBN nie powinien być akceptowany jako klucz kandydujący w skomputeryzowanej bazie danych? Oczywiście nie. Jedną z zalet ISBN jest to, że ma zaufane źródło, które rozwiąże problemy dla wszystkich użytkowników na całym świecie.

Istnieją inne właściwości dobrego klucza, że ​​ISBN ma brak bezsensownego automatycznego zwiększania liczby całkowitej, np. Znajomość (każdy w branży książkowej zna lub zna ISBN), weryfikowalny (ISBN jest drukowany na wszystkich współczesnych książkach), może być sprawdzony w odniesieniu do DBMS (ISBN ma stałą szerokość i zawiera sumę kontrolną) itp.

oneedaywhen
źródło
3
ISBN ma stałą szerokość, z wyjątkiem sytuacji, gdy nie jest (patrz ISBN-10 vs ISBN-13).
CVn
Jak więc zarekomendowałbyś obsługę zduplikowanych numerów ISBN? We wszystkich RDBMSach, o których wiem, trzeba by mieć ograniczenie UNIQUE na polu, aby użyć go jako klucza podstawowego.
Wildcard,
1

Wszystko, co może być niezmienne, powinno być. Pomaga zapewnić poprawność i pomaga, gdy chcesz, aby aplikacja była wielowątkowa.

dash-tom-bang
źródło
1

Tak, klucz podstawowy musi być niezmienny, a także być niepusty i niepowtarzalny. Jednak muszę jeszcze znaleźć bazę danych, która wymusi niezmienność kluczy głównych, więc prawdopodobnie możesz iść naprzód i zmienić ich wartości, jeśli naprawdę chcesz.

Bob Jarvis - Przywróć Monikę
źródło
0

Jak już wspomniano w niektórych komentarzach, jednym z rozwiązań jest użycie nowego klucza podstawowego

Na przykład (zgodnie z przykładem @onayaywhen), powiedzmy, że istnieje tabela Książki, która przechowuje listę książek, a my „użyliśmy” do ustalenia ISBN jako klucza podstawowego. Jednak niektórzy autorzy popełnili błąd, wpisując niewłaściwy numer ISBN, więc poprosili o zmianę numeru ISBN, dotyczyło to kolejnych zadań:

  • utwórz nowy rejestr w tabeli Książki
  • wskaż wszystkie odniesienia ze starego ISBN do nowego ISBN. (*)
  • Na koniec usuń stary rejestr z tabeli Książki.

(*) może to być trywialne znalezienie wszystkich referencji dla modelu bazy danych, który używa kluczy obcych, ale niektóre modele go nie mają.

Table Books
ISBN  is the primary key
NAME is a simple field.
etc.

Zmieniamy to jako

Table Books
InternalBookId as the primary key
ISBN as a simple field or an indexed field.
NAME is a simple field.
etc.

Gdzie nowy InternalBookId może być nawet wartością autonumeryczną.

Wady na ten temat:

  • dodaje nowe pole, które wykorzystuje więcej miejsca / zasobów.

  • może wymagać przepisania całego modelu.

  • nowy model może być mniej samoobjaśniający.

Profesjonalista

  • Pozwala mutować „klucz podstawowy”.
  • Pozwala nawet upuścić lub zrefaktoryzować „klucz podstawowy”, na przykład zmienić Książki na ISBN-13 jest tak proste, że upuszcza starszą kolumnę i tworzy nową

Nowy stół:

Table Books
InternalBookId as the primary key
ISBN13 is a new field.
NAME is a simple field.
etc.
magallanes
źródło