Jaka jest najlepsza praktyka dla kluczy podstawowych w tabelach?


256

Projektując tabele, wyrobiłem sobie nawyk posiadania jednej kolumny, która jest unikalna i że tworzę klucz podstawowy. Osiąga się to na trzy sposoby w zależności od wymagań:

  1. Kolumna z liczbą całkowitą tożsamości, która automatycznie zwiększa.
  2. Unikalny identyfikator (GUID)
  3. Kolumna z krótkim znakiem (x) lub liczbą całkowitą (lub innym stosunkowo niewielkim typem liczbowym), która może służyć jako kolumna z identyfikatorem wiersza

Liczba 3 byłaby używana do dość małych wyszukiwań, głównie do odczytu tabel, które mogą mieć unikalny statyczny kod łańcuchowy długości lub wartość liczbową, taką jak rok lub inna liczba.

W przeważającej części wszystkie pozostałe tabele będą miały albo automatycznie zwiększającą się liczbę całkowitą, albo klucz podstawowy unikalnego identyfikatora.

Pytanie :-)

Niedawno zacząłem pracować z bazami danych, które nie mają spójnego identyfikatora wiersza, a klucze podstawowe są obecnie skupione w różnych kolumnach. Kilka przykładów:

  • data / godzina
  • datetime / integer
  • datetime / varchar
  • char / nvarchar / nvarchar

Czy jest na to uzasadniony przypadek? Dla tych przypadków zawsze zdefiniowałbym kolumnę tożsamości lub unikalnego identyfikatora.

Ponadto istnieje wiele tabel bez kluczy podstawowych. Jakie są uzasadnione powody, jeśli takie istnieją?

Próbuję zrozumieć, dlaczego stoły zostały zaprojektowane w takiej formie, w jakiej były, i wydaje mi się, że to wielki bałagan, ale może były ku temu dobre powody.

Trzecie pytanie, które może mi pomóc odszyfrować odpowiedzi: Czy w przypadku, gdy wiele kolumn zawiera złożony klucz podstawowy, czy ta metoda ma szczególną zaletę w porównaniu z kluczem zastępczym / sztucznym? Myślę głównie o wydajności, konserwacji, administracji itp.?


Znalazłem Umiejętności bazy danych: Rozsądne podejście do wyboru kluczy podstawowych jako dobrą lekturę i podążam za większością przedstawionych punktów.
user2864740,

Odpowiedzi:


254

Przestrzegam kilku zasad:

  1. Klucze podstawowe powinny być tak małe, jak to konieczne. Preferuj typ liczbowy, ponieważ typy numeryczne są przechowywane w znacznie bardziej kompaktowym formacie niż formaty znaków. Wynika to z faktu, że większość kluczy podstawowych będzie kluczami obcymi w innej tabeli, a także będzie używana w wielu indeksach. Im mniejszy klucz, tym mniejszy indeks, tym mniej stron w pamięci podręcznej będzie używanych.
  2. Klucze podstawowe nigdy nie powinny się zmieniać. Aktualizacja klucza podstawowego zawsze powinna być wykluczona. Wynika to z faktu, że najprawdopodobniej jest używany w wielu indeksach i używany jako klucz obcy. Aktualizacja pojedynczego klucza podstawowego może powodować falowy efekt zmian.
  3. NIE używaj „klucza podstawowego problemu” jako klucza podstawowego modelu logicznego. Na przykład numer paszportu, numer ubezpieczenia społecznego lub numer umowy pracowniczej, ponieważ te „klucze podstawowe” mogą ulec zmianie w rzeczywistych sytuacjach.

W przypadku klucza zastępczego vs. klucza naturalnego odsyłam do powyższych zasad. Jeśli klucz naturalny jest mały i nigdy się nie zmieni, można go użyć jako klucza podstawowego. Jeśli klucz naturalny jest duży lub może się zmienić, używam kluczy zastępczych. Jeśli nie ma klucza podstawowego, nadal tworzę klucz zastępczy, ponieważ doświadczenie pokazuje, że zawsze dodasz tabele do schematu i żałuję, że nie umieściłeś klucza podstawowego na swoim miejscu.


3
Lubię to! Czy masz dokumentację na podstawie swoich „zasad”? Dzięki!
Lloyd Cotten,

4
Nie, po prostu doświadczenie. W przypadku „małych” baz danych rzeczy te nie mają tak wielkiego znaczenia. Ale kiedy masz do czynienia z dużymi bazami danych, wszystkie małe rzeczy mają znaczenie. Wyobraź sobie, że masz 1 miliard wierszy z int lub długimi pk w porównaniu do używania tekstu lub przewodników. Jest ogromna różnica!
Logicalmind,

44
Pamiętaj tylko, aby umieścić ten unikalny indeks na kluczu naturalnym (jeśli tak naprawdę istnieje, co często nie jest prawdą), gdy używasz klucza sztucznego.
HLGEM

3
@Lloyd Cotten: Oto, co mówi dostawca silnika dużych zbiorów danych na poparcie reguły nr 1: skyfoundry.com/forum/topic/24 . Przekonał mnie, żebym wrócił do Ints
płyt

4
nawet jeśli „wiesz”, że „naturalny klucz jest mały i nigdy się nie zmieni”, zastanów się dwa razy. „nigdy więcej nie używamy tych kodów” to słynne ostatnie słowa… O jedynych rzeczach, które należą do kategorii małych, nigdy nie zmieniających się, są ISO i inne standardy (kody krajów, kody lotnisk iata). Rzeczy takie jak „jaka jest dwuliterowa reprezentacja tej wewnętrznej marki” ... zastanów się dwa razy, zanim przyjmiesz, że „to” nigdy się nie zmieni, jesteś jedną decyzją finansową od przebudowy bazy danych.
Andrew Hill,

90

Sztuczne klucze wierszy naturalnych są rodzajem debaty religijnej wśród społeczności baz danych - zobacz ten artykuł i inne, do których prowadzi łącze. Nie jestem ani za zawsze posiadających klucze sztucznych, ani nigdy o nich. Zdecydowałbym się na każdy przypadek, na przykład:

  • Stany Zjednoczone: wybrałbym kod stanu („TX” dla Teksasu itp.), Zamiast state_id = 1 dla Teksasu
  • Pracownicy: zwykle tworzyłem sztuczny identyfikator pracownika, ponieważ trudno jest znaleźć coś, co działa. Numer SSN lub równoważny może działać, ale mogą wystąpić problemy, takie jak nowy stolarz, który nie podał jeszcze swojego numeru SSN.
  • Historia wynagrodzeń pracowników: (identyfikator_początka, data_początkowa). Chciałbym nie tworzyć sztuczne employee_salary_history_id. W jakim sensie by to służyło (inne niż „głupia konsekwencja” )

Wszędzie tam, gdzie używane są klucze sztuczne, należy zawsze deklarować unikalne ograniczenia dotyczące kluczy naturalnych. Na przykład użyj state_id, jeśli musisz, ale lepiej zadeklaruj unikalne ograniczenie kodu stanu, w przeciwnym razie na pewno skończysz z:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas

9
W niektórych przypadkach z SQL Server 2005/2008 klucz naturalny (tekstowy) może być szybszy niż klucz int. Mam aplikację z kodem przyjaznym dla 7-8 znaków, którego używamy jako klucza podstawowego i który był szybszy (i często wygodniejszy) niż surogat int. W każdym razie potrzebowaliśmy kodu, abyśmy mogli mieć czytelny dla człowieka / niezapomniany kod, który moglibyśmy bezpiecznie przenieść bez konfliktu do innej instancji aplikacji (wiele witryn, które agregują w większą witrynę).
lambacck

1
+1 Dobra odpowiedź. Jednak sprawiłbym, że urzędnik ds. Personalnych stał się zaufanym źródłem identyfikatora pracownika, tj. Urzędnika odpowiedzialnego za weryfikację pracowników w prawdziwym życiu, którzy prawdopodobnie używają identyfikatorów, takich jak SSN, przyjmują referencje itp. Dział personalny musi być zaufany źródło identyfikatorów pracowników, a nie DBMS!
poniedziałek

@ onedaywhen- Nie chciałbym. zaufaj funkcjonariuszowi personelu. Ludzie odchodzą, przychodzą nowi i mają różne pomysły. Zapewnienie im dostępu do identyfikatora ich zdaniem jest wyjątkowy / chcą używać, ale wewnętrznie na db, dba należy podejmowania własnych decyzji
Dave Pile

1
Pamiętaj, że SSN niekoniecznie jest unikalny w każdym kraju. Przynajmniej w Austrii wiele osób może mieć ten sam numer
maja

Również w niektórych krajach (myślę, że nawet w USA) tak naprawdę zalecają, aby nie udostępniać SSN.
Stijn de Witt

25

Tylko dodatkowy komentarz do czegoś, co często jest pomijane. Czasami niestosowanie klucza zastępczego ma zalety w tabelach potomnych. Załóżmy, że mamy projekt, który umożliwia prowadzenie wielu firm w ramach jednej bazy danych (być może jest to rozwiązanie hostowane lub cokolwiek innego).

Powiedzmy, że mamy te tabele i kolumny:

Company:
  CompanyId   (primary key)

CostCenter:
  CompanyId   (primary key, foreign key to Company)
  CostCentre  (primary key)

CostElement
  CompanyId   (primary key, foreign key to Company)
  CostElement (primary key)

Invoice:
  InvoiceId    (primary key)
  CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)
  CostCentre   (in foreign key to CostCentre)
  CostElement  (in foreign key to CostElement)

Jeśli ten ostatni bit nie ma sensu, Invoice.CompanyIdjest częścią dwóch kluczy obcych, jednego do tabeli CostCentre i jednego do tabeli CostElement . Klucz podstawowy jest ( InvoiceId , CompanyId ).

W tym modelu nie można zepsuć i odwołać się do CostElement z jednej firmy i CostCentre z innej firmy. Gdyby w tabelach CostElement i CostCentre użyto klucza zastępczego , byłoby to możliwe.

Im mniej szans na zepsucie, tym lepiej.


6
Jest to niedoceniana wada przy korzystaniu z kluczy zastępczych. Jeśli tabela ma klucz zastępczy, nadal mogę go używać do tego rodzaju ograniczeń. Niestety ograniczenie wymaga indeksu i po prostu dziwne jest tworzenie unikalnego indeksu dla (surrogate_key, other_column), gdy (surrogate_key) jest samo w sobie unikalne. Ponadto (inna_kolumna) jest często całkowicie zbędna w tabeli map, ponieważ (surrogate_key) jest unikalny w obcej. Surogaci mogą naprawdę zepsuć wszystko.
Samuel Danielson

24

Unikam używania kluczy naturalnych z jednego prostego powodu - błędu ludzkiego. Chociaż naturalne unikalne identyfikatory są często dostępne (SSN, VIN, numer konta itp.), Wymagają one od człowieka prawidłowego wprowadzenia ich. Jeśli używasz SSN jako klucza podstawowego, ktoś transponuje kilka liczb podczas wprowadzania danych, a błąd nie zostanie natychmiast wykryty, wówczas musisz zmierzyć się z kluczem podstawowym.

Moje podstawowe klucze są obsługiwane przez program bazy danych w tle i użytkownik nigdy ich nie zna.


1
Pracowałem z kilkoma bazami danych, które wykorzystywały SSN lub NIP jako klucze podstawowe. Niewystarczające, jeśli chodzi o pamięć i odwołania do kluczy obcych. Nie wspominając o tym, że SSN danej osoby może się zmienić. Więc całkowicie się z tobą zgadzam.
Alex Jorgenson

13

Utworzenie klucza podstawowego z różnych dziedzin nie stanowi problemu, to klucz naturalny .

Możesz użyć kolumny Tożsamość (powiązanej z unikalnym indeksem w polach kandydujących), aby utworzyć klucz zastępczy .

To stara dyskusja. W większości sytuacji wolę klucze zastępcze.

Ale nie ma usprawiedliwienia dla braku klucza.

RE: EDYCJA

Tak, istnieje wiele kontrowersji na ten temat: D

Nie widzę żadnej oczywistej przewagi nad naturalnymi kluczami, poza tym, że są one naturalnym wyborem. Zawsze będziesz myśleć w Name, SocialNumber - lub coś w tym rodzaju - zamiast idPerson .

Klucze zastępcze są odpowiedzią na niektóre problemy, które mają klucze naturalne (na przykład propagowanie zmian).

Kiedy przyzwyczaisz się do surogatów, wydaje się to bardziej czyste i łatwiejsze do zarządzania.

Ale w końcu przekonasz się, że to tylko kwestia gustu - lub sposobu myślenia. Ludzie „myślą lepiej” dzięki naturalnym kluczom, a inni nie.


13
Ludzie „myślą lepiej” dzięki naturalnym kluczom. Maszyny i bazy danych, nie.
FDCastel

11

Tabele powinny cały czas mieć klucz podstawowy. Kiedy tak nie jest, powinny to być pola AutoIncrement.

Czasami ludzie pomijają klucz podstawowy, ponieważ przesyłają dużo danych, co może spowolnić (zależnie od bazy danych) proces. ALE, należy go dodać po nim.

Jeden komentarz na temat tabeli linków , to prawda, jest to wyjątek, ALE pola powinny być FK, aby zachować integralność, a czasami te pola mogą być kluczami podstawowymi, jeśli duplikat w linkach nie jest autoryzowany ... ale aby zachować prosta forma, ponieważ wyjątek występuje często w programowaniu, klucz podstawowy powinien być obecny, aby zachować integralność danych.


Zgadzam się. A w przypadku, gdy trzeba wstawić dużo danych, usuń ograniczenie klucza podstawowego (lub użyj INSERT IDENTITY ON w TSQL) i odłóż je później :)
Andrew Rollings

1
Istnieją wyjątki: tabele linków oczywiście
annakata

Kolejny powód: jeśli nie ma klucza PK / unikalnego, przeglądarki tabel (mam na myśli coś takiego jak Access / SQL Server Management Studio) odmówią aktualizacji / usunięcia pojedynczego wiersza ze zduplikowanym wierszem. W tym celu musisz napisać SQL.
Dennis C,

Dość często pomija się PK w tabeli faktów hurtowni danych. W Oracle możesz odwołać się do pseudokolumny ROWID jako unikalnego identyfikatora w krótkim okresie (tj. Nie przechowuj go gdzieś i spodziewaj się, że się nie zmieni)
David Aldridge

9

Oprócz tych wszystkich dobrych odpowiedzi, chcę tylko podzielić się dobrym artykułem, który właśnie przeczytałem, Wielka debata na temat klucza podstawowego .

Wystarczy przytoczyć kilka punktów:

Deweloper musi zastosować kilka zasad przy wyborze klucza podstawowego dla każdej tabeli:

  • Klucz podstawowy musi jednoznacznie identyfikować każdy rekord.
  • Wartość klucza podstawowego rekordu nie może być pusta.
  • Podstawowy klucz-wartość musi istnieć podczas tworzenia rekordu.
  • Klucz podstawowy musi pozostać stabilny - nie można zmienić pola (pól) klucza podstawowego.
  • Klucz podstawowy musi być zwarty i zawierać możliwie najmniej atrybutów.
  • Wartości klucza podstawowego nie można zmienić.

Naturalne klucze (zwykle) łamią zasady. Klucze zastępcze są zgodne z zasadami. (Lepiej przeczytaj ten artykuł, warto poświęcić czas!)


7

Co jest specjalnego w kluczu podstawowym?

Jaki jest cel tabeli w schemacie? Jaki jest cel klucza stołu? Co jest specjalnego w kluczu podstawowym? Dyskusje na temat kluczy podstawowych wydają się nie uwzględniać tego, że klucz podstawowy jest częścią tabeli, a ta tabela jest częścią schematu. To, co jest najlepsze dla tabeli i relacji między tabelami, powinno kierować używanym kluczem.

Tabele (i relacje między tabelami) zawierają fakty dotyczące informacji, które chcesz zapisać. Fakty te powinny być niezależne, znaczące, łatwe do zrozumienia i niesprzeczne. Z perspektywy projektowania inne tabele dodane lub usunięte ze schematu nie powinny wpływać na tabelę. Musi istnieć cel przechowywania danych związanych tylko z samą informacją. Zrozumienie tego, co jest przechowywane w tabeli, nie powinno wymagać poddania się projektowi badań naukowych. Żaden fakt przechowywany w tym samym celu nie powinien być przechowywany więcej niż jeden raz. Klucze to całość lub część zapisywanych informacji, która jest unikalna, a klucz podstawowy to specjalnie wyznaczony klucz, który ma być głównym punktem dostępu do tabeli (tzn. Powinien zostać wybrany ze względu na spójność i wykorzystanie danych, a nie tylko wstawianie występ).

  • NA BOK: Niestety efektem ubocznym większości baz danych projektowanych i rozwijanych przez programistów aplikacji (którym czasami jestem) jest to, że to, co najlepsze dla aplikacji lub frameworka aplikacji, często decyduje o wyborze klucza podstawowego dla tabel. Prowadzi to do liczb całkowitych i kluczy GUID (ponieważ są one łatwe w użyciu w ramach aplikacji) i monolitycznych projektów tabel (ponieważ zmniejszają one liczbę obiektów struktury aplikacji potrzebnych do reprezentowania danych w pamięci). Te decyzje projektowe baz danych oparte na aplikacjach prowadzą do poważnych problemów z spójnością danych, gdy są stosowane w skali. Ramy aplikacji zaprojektowane w ten sposób w naturalny sposób prowadzą do tworzenia tabel na raz. „Częściowe rekordy” są tworzone w tabelach i danych wypełnianych w miarę upływu czasu. Unika się interakcji z wieloma tabelami lub gdy użycie powoduje niespójne dane, gdy aplikacja działa nieprawidłowo. Te projekty prowadzą do danych, które nie mają znaczenia (lub są trudne do zrozumienia), danych rozłożonych na tabele (musisz spojrzeć na inne tabele, aby zrozumieć aktualną tabelę) i zduplikowanych danych.

Mówiono, że klucze podstawowe powinny być tak małe, jak to konieczne. Powiedziałbym, że klucze powinny być tak duże, jak to konieczne. Należy unikać losowego dodawania nieistotnych pól do tabeli. Jeszcze gorzej jest zrobić klucz z losowo dodanego, pozbawionego znaczenia pola, szczególnie gdy niszczy zależność łączenia z innej tabeli do klucza innego niż podstawowy. Jest to uzasadnione tylko wtedy, gdy nie ma dobrych kluczy kandydujących w tabeli, ale to z pewnością jest oznaką złego projektu schematu, jeśli jest stosowane we wszystkich tabelach.

Mówiono również, że klucze podstawowe nigdy nie powinny się zmieniać, ponieważ aktualizacja klucza podstawowego zawsze powinna być wykluczona. Ale aktualizacja jest taka sama jak usuwanie, a następnie wstawianie. Zgodnie z tą logiką nigdy nie należy usuwać rekordu z tabeli za pomocą jednego klucza, a następnie dodawać kolejny rekord za pomocą drugiego klucza. Dodanie zastępczego klucza podstawowego nie usuwa faktu, że istnieje inny klucz w tabeli. Aktualizacja klucza innego niż podstawowy tabeli może zniszczyć znaczenie danych, jeśli inne tabele mają zależność od tego znaczenia za pomocą klucza zastępczego (np. Tabela statusu z kluczem zastępczym, którego opis statusu został zmieniony z „Przetworzone” na „Anulowane” „zdecydowanie uszkodziłoby dane). To, co zawsze powinno być wykluczone, to niszczenie znaczenia danych.

Powiedziawszy to, jestem wdzięczny za wiele źle zaprojektowanych baz danych, które istnieją w dzisiejszych firmach (behemoty pozbawione znaczenia-zastępcze-dane-uszkodzone-1NF), ponieważ oznacza to, że ludzie, którzy rozumieją odpowiedni projekt bazy danych, mają nieskończoną ilość pracy. . Ale ze smutnej strony, czasami sprawia, że ​​czuję się jak Syzyf, ale założę się, że miał jeden 401k (przed katastrofą). Trzymaj się z dala od blogów i stron internetowych w przypadku ważnych pytań dotyczących projektowania baz danych. Jeśli projektujesz bazy danych, wyszukaj Data CJ. Możesz także odwoływać się do Celko dla SQL Server, ale tylko jeśli najpierw trzymasz nos. Po stronie Oracle odwołaj się do Tom Kyte.


1
„Zgodnie z tą logiką nigdy nie należy usuwać rekordu z tabeli za pomocą jednego klucza, a następnie dodawać kolejny rekord za pomocą drugiego klucza”. - Jest ku temu uzasadnienie i właśnie to robi klauzula „ON DELETE RESTRICT” na kluczu obcym. W niektórych przypadkach (np. Gdy wymagana jest ścieżka audytu) lepsze byłoby „usunięcie” pola logicznego niż umożliwienie usunięcia rekordu.
Waz

6

Naturalny klucz, jeśli jest dostępny, jest zwykle najlepszy. Tak więc, jeśli datetime / char jednoznacznie identyfikuje wiersz, a obie części mają znaczenie dla wiersza, to świetnie.

Jeśli tylko data i godzina są znaczące, a znak charak- teryzowany jest tak, aby uczynić go unikalnym, to równie dobrze możesz po prostu użyć pola identyfikującego.


9
Zwykle najlepszy? Nie mam żadnych podstaw naukowych, ale jestem prawie pewien, że większość ludzi woli klucz zastępczy niż naturalny. W wielu przypadkach nie ma naturalnego klucza.
JC.

3
ZAWSZE powinien istnieć naturalny klucz do dowolnego wiersza w bazie danych. Ten „naturalny” klucz może być czymś generowanym w świecie biznesu lub przez twój system techniczny, ale zawsze powinien istnieć.
Tom H

2
Jeśli w twoim świecie ustalono, że jest to jedyny sposób na identyfikację wiersza w tabeli, to tak. Oczywiście, kiedy projektant zdecyduje się utworzyć identyfikator GUID dla PK, zwykle dzieje się tak, ponieważ nie wykonał pracy, aby znaleźć PRAWDZIWY klucz naturalny, więc w takim przypadku GUID NIE jest kluczem naturalnym.
Tom H

8
2. Jeśli zabierzesz swój klucz ze świata naturalnego, świat naturalny zmieni się, aby złamać twój klucz. Jeśli użyjesz numeru telefonu, uzyskasz dwóch użytkowników z tego samego gospodarstwa domowego. Jeśli użyjesz nazwiska, pobiorą się. Jeśli korzystasz z SSN, przepisy dotyczące prywatności zmienią się i będą wymagać ich usunięcia.
James Orr,

2
@Barry: RE: # 2. jeśli świat naturalny się zmieni, a to spowoduje zmianę twojego naturalnego klucza, oznacza to, że źle wykonałeś wybranie naturalnego klucza. Z definicji naturalny klucz nie zmienia się z czasem.
Tom H

6

Oto moja własna zasada, na którą zdecydowałem się po ponad 25 latach doświadczenia w programowaniu.

  • Wszystkie tabele powinny mieć klucz podstawowy z jedną kolumną, który automatycznie zwiększa.
  • Uwzględnij go w dowolnym widoku, który ma być aktualizowany
  • Klucz podstawowy nie powinien mieć żadnego znaczenia w kontekście aplikacji. Oznacza to, że nie powinien to być numer SKU, numer konta, identyfikator pracownika ani żadna inna informacja, która ma znaczenie dla Twojej aplikacji. Jest to tylko unikalny klucz związany z bytem.

Klucz podstawowy jest używany przez bazę danych do celów optymalizacji i nie powinien być wykorzystywany przez aplikację do niczego więcej niż do identyfikacji konkretnego podmiotu lub odnoszącego się do konkretnego podmiotu.

Zawsze posiadanie klucza podstawowego o pojedynczej wartości sprawia, że ​​wykonywanie UPSERT jest bardzo proste.

Użyj dodatkowych indeksów do obsługi kluczy wielokolumnowych, które mają znaczenie w Twojej aplikacji.


5

Dla mnie klucze naturalne a sztuczne to kwestia tego, ile logiki biznesowej chcesz w swojej bazie danych. Doskonały przykład to numer ubezpieczenia społecznego (SSN).

„Każdy klient w mojej bazie danych ma i musi mieć SSN”. Bam, gotowe, uczyń to kluczem podstawowym i gotowe. Pamiętaj tylko, że kiedy zmieniają się reguły biznesowe, jesteś spalony.

Nie lubię naturalnych kluczy, ponieważ mam doświadczenie w zmienianiu reguł biznesowych. Ale jeśli jesteś pewien, że się nie zmieni, może to uniemożliwić kilka krytycznych połączeń.


8
Widziałem dane, w których SSN nie jest unikalny, nawet jeśli powinien. Uważaj na naturalne klucze, jeśli importujesz dane z innego źródła!
HLGEM,

2
Jeśli jesteś przedmiotem kradzieży tożsamości, możesz zmienić swój numer ubezpieczenia społecznego. Są jeszcze cztery sytuacje, w których zmienią twój numer i są wymienione na stronie ssa.gov.
Zvi Twersky,

4

Podejrzewam, że zwinięta gazeta Stevena A. Lowe'a jest wymagana od projektanta oryginalnej struktury danych.

Nawiasem mówiąc , identyfikatory GUID jako klucz podstawowy mogą być świnią wydajności. Nie poleciłbym tego.


2
Powiedzieć, że to wieprz wydajności jest przedwczesną optymalizacją. W niektórych przypadkach wymagane są przewodniki (rozłączeni klienci, przyszłe scalanie tabel, replikacja)
JC.

2
„Optymalizacja przedwczesna” to nadużywana fraza na SO (IMHO)! Tak, identyfikatory GUID mogą być wymagane w NIEKTÓRYCH przypadkach, ale Andrew słusznie zauważa, że ​​nie należy ich używać jako domyślnego typu danych, czy jest to wymagane, czy nie.
Tony Andrews,

OK, to nie była przedwczesna optymalizacja. Miałem na myśli to, że większość ludzi nie odczuwa głośności wymaganej do zauważenia różnicy w wydajności. Tak, skorzystaj z autoinkrementacji, jeśli wiesz, że nigdy nie będziesz potrzebować przewodnika.
JC.

Lub użyj obu. Posiadaj klucz główny oparty na int / long, aby ładnie wybierać i łączyć, a następnie mieć pole GUID. Przynajmniej tak robię. Czy to źle? Nie powinienem tego robić? :)
Andrew Rollings,

Używam również obu kolumn. Ale nie jestem pewien, czy to źle, czy nie. Znalazłeś to @AndrewRollings?
YÒGÎ

3

Należy użyć klucza podstawowego „złożony” lub „złożony”, który składa się z wielu pól.

Jest to całkowicie akceptowalne rozwiązanie, przejdź tutaj, aby uzyskać więcej informacji :)


3

Ja też zawsze używam numerycznej kolumny identyfikacyjnej. W wyroczni używam liczby (18,0) bez żadnego rzeczywistego powodu powyżej liczby (12,0) (lub cokolwiek, co jest liczbą całkowitą zamiast długiej), może po prostu nie chcę się martwić o uzyskanie kilku miliardów wierszy w db!

Dołączam również utworzoną i zmodyfikowaną kolumnę (znacznik czasu typu) do podstawowego śledzenia, gdzie wydaje się to przydatne.

Nie mam nic przeciwko tworzeniu unikalnych ograniczeń dla innych kombinacji kolumn, ale naprawdę podoba mi się mój identyfikator, utworzone, zmodyfikowane wymagania linii bazowej.


2
Muszę również zaznaczyć, że nie umieszczam identyfikatorów w tabelach linków / złączeń, tylko w tabelach zawierających dane.
JeeBee,

3

Poszukuję naturalnych kluczy podstawowych i używam ich tam, gdzie mogę.

Jeśli nie można znaleźć żadnych kluczy naturalnych, wolę GUID niż INT ++, ponieważ SQL Server używa drzew i źle jest zawsze dodawać klucze na końcu w drzewach.

W tabelach, które są połączeniami wiele do wielu, używam złożonego klucza podstawowego kluczy obcych.

Ponieważ mam szczęście korzystać z programu SQL Server, mogę analizować plany wykonania i statystyki za pomocą profilera i analizatora zapytań oraz dowiedzieć się, jak bardzo działają moje klucze.


Czy masz dokumentację, aby wykonać kopię zapasową tego oświadczenia: „jeśli nie można znaleźć kluczy naturalnych, wolę identyfikator GUID niż INT ++, ponieważ SQL Server używa drzew, a źle jest zawsze dodawać klucze na końcu drzewa”. Nie sceptycznie, po prostu próbuję skompilować trochę dokumentacji.
Lloyd Cotten,

1
@ Lloyd - Cieszę się, że interesujesz się czymś, co bardzo mnie fascynuje. Dobry punkt wyjścia na msdn.microsoft.com/en-us/library/ms177443(SQL.90).aspx
Guge

2

Zawsze używam automatycznego numeru lub pola tożsamości.

Pracowałem dla klienta, który użył SSN jako klucza podstawowego, a następnie z powodu przepisów HIPAA został zmuszony do zmiany na „MemberID”, co spowodowało mnóstwo problemów podczas aktualizacji kluczy obcych w powiązanych tabelach. Trzymanie się spójnego standardu kolumny tożsamości pomogło mi uniknąć podobnego problemu we wszystkich moich projektach.


6
Niewłaściwy wybór klucza naturalnego przez programistę nie oznacza, że ​​klucze naturalne są złe.
Tom H

1
Narzędzie trudne w użyciu nie jest w jakiś sposób przeciwne temu narzędziu?
Sqeaky

1

Wszystkie tabele powinny mieć klucz podstawowy. W przeciwnym razie masz HEAP - w niektórych sytuacjach może to być to, czego potrzebujesz (duże obciążenie wstawiania, gdy dane są następnie replikowane za pośrednictwem brokera usług do innej bazy danych lub tabeli).

W przypadku tabel wyszukiwania z małą liczbą wierszy można użyć kodu 3 CHAR jako klucza podstawowego, ponieważ zajmuje to mniej miejsca niż INT, ale różnica w wydajności jest znikoma. Poza tym zawsze używałbym INT, chyba że masz tabelę referencyjną, która być może ma złożony klucz podstawowy złożony z kluczy obcych z powiązanych tabel.


1

Jeśli naprawdę chcesz przeczytać całą tę i z powrotem tę odwieczną debatę, poszukaj „naturalnego klucza” w przepełnieniu stosu. Powinieneś odzyskać strony wyników.


1

Identyfikatory GUID mogą być używane jako klucz podstawowy, ale musisz utworzyć odpowiedni typ identyfikatora GUID, aby działał dobrze.

Musisz wygenerować identyfikatory GUI COMB. Dobry artykuł na ten temat i statystyki wydajności to Koszt identyfikatorów GUID jako kluczy podstawowych .

Również część kodu do budowania identyfikatorów GUI COMB w SQL znajduje się w Uniqueidentifier vs. tożsamości ( archiwum ) .


5
IMHO, przewodników należy używać tylko wtedy, gdy trzeba synchronizować dane między bazami danych. W którym automatycznie generowany identyfikator jest problematyczny. Różnica między użyciem GUID a użyciem podstawowego typu liczbowego polega na tym, że GUID będzie wymagał 16 bajtów na wiersz, podczas gdy numeryczny będzie znacznie mniejszy.
Logicalmind,

Jeśli przejdziesz do linku, który podałem powyżej, różnica w wydajności przy użyciu Przewodników COMB jest niewielka.
Donny V.

0

Wykonujemy wiele sprzężeń, a złożone klucze podstawowe właśnie stały się świnią wydajności. Prosta int lub długa rozwiązuje wiele problemów, nawet jeśli wprowadzasz drugi klucz kandydata, ale dołączenie do jednej dziedziny jest łatwiejsze i bardziej zrozumiałe.


1
Ta strategia rozpada się, gdy musisz przejść przez 6 tabel, aby połączyć dwie rzeczywiste tabele, których potrzebujesz, ponieważ klucze kompozytowe nie zostały propagowane. Skończyło się to również na użyciu pętli / kursorów dla wielu wkładek, które mogą być OGROMNYM wieprzowym występem.
Tom H

2
Nie jestem zbyt duża, aby nauczyć się czegoś nowego. Chciałbym zobaczyć przykład tego, co mówisz, pomocne byłoby wprowadzenie racjonalnego faktu w niektóre z tych religijnych argumentów.
Dan Blair,

0

Będę z góry poinformowany o moich preferencjach dotyczących kluczy naturalnych - używaj ich tam, gdzie to możliwe, ponieważ znacznie ułatwią Ci administrowanie bazą danych. W naszej firmie ustaliłem, że wszystkie tabele mają następujące kolumny:

  • Identyfikator wiersza (GUID)
  • Creator (string; domyślnie ma nazwę bieżącego użytkownika ( SUSER_SNAME()w T-SQL))
  • Utworzono (DateTime)
  • Znak czasu

Identyfikator wiersza ma unikatowy klucz na tabelę, a w każdym przypadku jest generowany automatycznie dla wiersza (a uprawnienia uniemożliwiają każdemu edytowanie go) i można zagwarantować, że będzie unikalny we wszystkich tabelach i bazach danych. Jeśli którykolwiek system ORM potrzebuje jednego klucza identyfikacyjnego, należy go użyć.

Tymczasem faktyczny PK jest, jeśli to możliwe, naturalnym kluczem. Moje wewnętrzne zasady są jak:

  • Ludzie - używaj klucza zastępczego, np. INT. Jeśli jest wewnętrzny, GUID użytkownika Active Directory jest akceptowalnym wyborem
  • Tabele przeglądowe (np. StatusCodes) - użyj krótkiego kodu CHAR; łatwiej jest zapamiętać niż INT, aw wielu przypadkach formularze papierowe i użytkownicy będą używać go również dla zwięzłości (np. Status = „E” dla „Wygasł”, „A” dla „Zatwierdzony”, „NADIS” dla „Nie wykryto azbestu” W próbce ”)
  • Łączenie tabel - kombinacja FK (np. EventId, AttendeeId)

Idealnym rozwiązaniem jest zatem posiadanie naturalnego, czytelnego dla człowieka i zapadającego w pamięć PK oraz przyjaznego dla ORM identyfikatora GUID z jednym identyfikatorem na stół.

Uwaga: bazy danych, które prowadzę, mają tendencję do gromadzenia 100 000 rekordów, a nie milionów czy miliardów, więc jeśli masz doświadczenie z większymi systemami, które są przeciwwskazane dla mojej rady, możesz mnie zignorować!


1
Czy sugerujesz utworzenie zarówno SK, jak GUID i INT SK dla tabel bez silnego naturalnego klucza?

Nie musisz, ale korzyści są następujące: a) ułatwia replikację, jeśli jej potrzebujesz, b) w przypadku ORM możesz przypisać unikalny identyfikator do obiektu w kodzie przed zapisaniem (co jest przydatne, jeśli trzeba wykonać wiele edycji na obiekcie, może przed zapisaniem w pamięci podręcznej sesji). Kluczem jest INT w tym przypadku; GUID to tylko bonus.
Keith Williams,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.