Czy klucz podstawowy powinien być niezmienny?

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?

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.

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.

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.

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

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.

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.

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

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.

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.