Kiedy nie używać zastępczych kluczy podstawowych?

Question

Mam kilka tabel bazy danych, które zawierają tylko jedną kolumnę i bardzo mało wierszy, często tylko identyfikator czegoś zdefiniowanego w innym systemie. Tabele te są następnie przywoływane za pomocą kluczy obcych z innych tabel. Na przykład jedna tabela zawiera kody krajów (SE, DK, US itd.). Wszystkie wartości są zawsze unikatowymi kluczami naturalnymi i są używane jako klucze podstawowe w innych (starszych) systemach.

Wydaje się naprawdę niepotrzebne wprowadzenie nowego klucza zastępczego do tych tabel, lub?

Na ogół, w jakich wyjątkowych przypadkach nie należy używać kluczy zastępczych?

Answer 1

powiedziałbym następujące kryteria muszą być spełnione:

• naturalną koniecznością klucz być absolutnie, pozytywnie, no-wyjątki-domowe, unikalne (rzeczy takie jak nazwiska, numery ubezpieczenia społecznego itp zwykle wydają się być wyjątkowy - ale naprawdę nie są)

• naturalną klucz powinien być tak mały, jak INT, np nie znacznie więcej niż 4 bajty (nie używaj VARCHAR (50) dla twojego PK, a zwłaszcza nie dla klucza klastrowania w SQL Server!)

• twój naturalny klucz powinien być stabilny, np. nigdy się nie zmieniają (OK, z kodem ISO kraju, to jest prawie dana - z wyjątkiem gdy kraje takie jak Jugosławii lub upadku ZSRR, albo inne podobne oboma państwami niemieckimi zjednoczyć - ale to na tyle rzadko)

Jeśli te warunki są spełnione, możesz wziąć pod uwagę naturalny klucz jako PK - ale to powinno być wyjątek 2% we wszystkich tabelach - nie jest to normą.

Answer 2

Klawisze fizyczne (kody krajów w danym przypadku) są lepsze, ponieważ

• one sensu, kiedy je zobaczyć (klucz zastępczy sam nic nie znaczy dla użytkownika. Jest to ważne dla programistów DB i opiekunów, którzy często musisz pracować z surowymi wyjściami DB)
• mniej połączeń (często potrzebujesz tylko kodu kraju i są już w innych tabelach.) Jeśli używasz zastępczych kluczy, musisz dołączyć do tabeli odnośników)

Wadą klawiszy naturalnych jest są powiązane z logiką informacyjną, a jeśli się zmienia (co się czasem zdarza), trzeba zmienić wiele tabel, zasadniczo zmieniając znaczną część bazy danych.

Tak więc, jeśli w twoim DB logika nie zmienia się przez wiele lat, użyj naturalnych kluczy.

Answer 3

Nie jestem pewien, czy istnieje przypadek wyjątku, gdy zastępcze klucze nie powinny być używane jako. Sądzę, że charakter zastępczego klucza, ogólnie mówiąc globalnie unikalny, jest szczególnie istotny, gdy stosuje się go do takiego systemu, jaki opisujesz.

Chociaż każdy z wymienionych kluczy satelitarnych może być unikalny w ramach ich własnego zakresu, nie można zagwarantować, że będą one unikatowe w całym zakresie połączonego środowiska, zwłaszcza jeśli się rozszerzy. Podejrzewam oryginalne projektantów były albo próbuje przyszłego dowód swojego systemu lub jazdy najnowszą modą oni nauczyli;)

Answer 4

Od dłuższej debaty na ten temat. Jeśli użyjesz google jako "surrogate v natural keys", uzyskasz wiele linków. Podejrzewam więc, że otrzymasz tutaj debatę, a nie jasną odpowiedź.

Od this article:

modelarzy danych (do tej dyskusji, ja to ktoś, kto zaprojektowane tabel dla bazy danych) są zgodni w tej kwestii: Niektórzy modelarze przysięgać zastępcza klucz; inni zginą, zanim użyją czegoś innego niż naturalnego klucza. Wyszukiwanie literatury na temat modelowania danych i projektowania baz danych nie obsługuje żadnej ze stron z wyjątkiem areny hurtowni danych, w której klucz zastępczy jest jedynym wyborem dla tabel wymiarów i faktów.

Answer 5

Oprócz tego, co marc_s powiedział, nie trzeba klucza surrgogate ogólnie w tabeli łączącej, która jest tabela, która zawiera dwa różne klucze podstawowe jedynie, że jest używany do tworzenia wiele do wielu relacji. Ogólnie klucz złożony na obu polach działa tutaj dobrze. Jest to jeden z nielicznych przypadków, w których sugeruję klucz złożony, generalnie preferuję klucz zastępczy i unikalny indeks na kluczu złożonym.

Answer 6

Używanie naturalnych kluczy do celów identyfikacyjnych jest dobrym pomysłem, gdy można zaufać naturalnym kluczom. Zobacz odpowiedź Marc_S w niektórych przypadkach, w których nie można zaufać kluczom naturalnym. Nie przejmuj się zbytnio wydajnością. Nawet coś takiego jak VIN (numer identyfikacyjny pojazdu) nie spowoduje zbyt dużego przeciągania bazy danych. Jeśli sądzisz, że to zrobisz, wykonaj kilka testów, zdając sobie sprawę, że wydajność nie skaluje się liniowo.

Głównym powodem zadeklarowania klucza głównego jest zapobieganie zsuwaniu się z pierwszej normalnej formy, a tym samym brak reprezentowania relacji. Użycie kluczu surogatycznego, który jest automatycznie odwracany, może skutkować dwoma wierszami z różnymi polami id, ale poza tym identyczne. Spowoduje to problemy związane z danymi, które nie występują w pierwszej normalnej formie. Użytkownicy nie będą w stanie Ci pomóc, ponieważ nie widzą pola identyfikatora.

Jeśli wiersze tabeli można określić za pomocą kombinacji dwóch lub więcej kluczy obcojęzycznych, masz do czynienia z tabelą powiązań, czasami nazywaną tabelą powiązań lub tabelą skrzyżowań. Zazwyczaj lepiej jest zadeklarować złożony klucz podstawowy, złożony ze wszystkich potrzebnych kluczy obcych.

Jeśli powyższe opcje spowodują powolną wydajność, czasami można temu zaradzić, tworząc dodatkowe indeksy. To zależy od tego, co robisz z danymi.