Naturalne wersety sztuczne klucze to rodzaj religijnej debaty wśród społeczności baz danych-zobacz Ten artykuł i inne linki do. Nie jestem ani za tym, aby Zawsze mieć sztuczne klucze, ani nigdy mieć je. Ja bym decydował indywidualnie, na przykład:

• stany USA: wybrałbym state_code ('TX' dla Teksasu itp.), zamiast state_id=1 dla Texas
• pracownicy: zwykle tworzyłbym sztuczny employeee_id, ponieważ jest to trudne znaleźć cokolwiek innego, co działa. SSN lub równoważny może działać, ale mogą wystąpić problemy, takie jak nowy stolarz, który nie dostarczył jeszcze swojej SSN.
• Historia wynagrodzeń pracowników: (employee_id, start_date). Chciałbymnie utworzyć sztuczny employee_salary_history_id. Jaki punkt by służył (inny niż "głupia konsystencja")

Wszędzie tam, gdzie używane są klucze sztuczne, należy również zadeklarować unikalne ograniczenia dla kluczy naturalnych. Na przykład użycie state_id jeśli musisz, ale wtedy lepiej zadeklaruj unikalne ograniczenie na state_code, w przeciwnym razie na pewno w końcu skończysz z:

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

Tylko dodatkowy komentarz na temat czegoś, co jest często pomijane. Czasami nie Używanie klucza zastępczego ma korzyści w tabelach dzieci. Załóżmy, że mamy projekt, który pozwala na uruchamianie wielu firm w jednej bazie danych(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)

W przypadku, gdy ostatni bit nie ma sensu, Invoice.CompanyId jest częścią dwóch kluczy obcych, jeden do tabeli CostCentre i jeden do CostElement tabela. Klucz podstawowy to (InvoiceId, CompanyId ).

W tym modelu nie można spieprzyć i odwołać się do CostElement z jednej firmy i CostCentre z innej firmy. Jeśli klucz zastępczy został użyty w tablicach CostElement i CostCentre , byłby.

Unikam używania klawiszy naturalnych z jednego prostego powodu-błędu ludzkiego. Chociaż często dostępne są naturalne unikalne identyfikatory (SSN, VIN, numer konta itp.), wymagają od człowieka poprawnego wprowadzenia do nich. Jeśli używasz SSN jako klucza podstawowego, ktoś transponuje kilka liczb podczas wprowadzania danych, a błąd nie zostanie natychmiast wykryty, wtedy masz do czynienia ze zmianą klucza podstawowego.

Moje klucze podstawowe są obsługiwane przez program bazodanowy w tle i użytkownika nigdy o nich nie wie.

Nie ma problemu z tworzeniem klucza podstawowego z różnych pól, jest to Klucz naturalny .

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

To stara dyskusja. Wolę klucze zastępcze w większości sytuacji.

Ale nie ma usprawiedliwienia dla braku klucza.

RE: EDIT

Tak, jest na ten temat wiele kontrowersji :d

Nie widzę żadnych oczywistą zaletą klawiszy naturalnych, poza tym, że są one naturalnym wyborem. Zawsze będziesz myśleć w Nazwa, SocialNumber - lub coś w tym stylu-zamiast idPerson .

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

Kiedy przyzwyczaisz się do surogatów, wydaje się to bardziej czyste i łatwe do opanowania.

Ale w końcu przekonasz się, że to tylko kwestia gustu - lub sposobu myślenia -. Ludzie "myślą lepiej" z naturalnymi kluczami, a inni nie.

Tabele powinny mieć cały czas klucz główny. Jeśli nie powinno to być Pole AutoIncrement.

Czasami ludzie pomijają klucz podstawowy, ponieważ przesyłają dużo danych i może to spowolnić (w zależności od bazy danych) proces. Ale należy go dodać po nim.

jakiś komentarz o tabeli linków , to prawda, jest to wyjątek, ale pola powinny być tak aby zachować integralność, a w niektórych przypadkach te pola mogą być kluczami podstawowymi, jeśli są duplikowane w linki nie są autoryzowane... ale aby zachować prostą formę, ponieważ wyjątek jest czymś często w programowaniu, klucz podstawowy powinien być obecny, aby zachować integralność danych.

Poza tymi wszystkimi dobrymi odpowiedziami, chcę podzielić się dobrym artykułem, który właśnie przeczytałem, wielki prawybór-kluczowa debata.

Żeby zacytować kilka punktów:

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

• klucz główny musi jednoznacznie identyfikować każdy rekord.
• wartość klucza podstawowego rekordu nie może być null.
• klucz podstawowy musi istnieć podczas tworzenia rekordu.
• klucz podstawowy musi pozostać stabilny-nie można zmienić pola klucza głównego.
• klucz podstawowy musi być zwarty i zawierać jak najmniej atrybutów.
• wartość klucza podstawowego nie może zostać zmieniona.

Klucze naturalne (zwykle) łamią zasady. Klucze zastępcze są zgodne z zasadami. (Lepiej przeczytaj ten artykuł, jest wart twojego czasu!)

Co jest specjalnego w kluczu głównym?

Jaki jest cel tabeli w schemacie? Jaki jest cel klucza tabeli? Co jest specjalnego w kluczu głównym? Dyskusje wokół kluczy podstawowych wydają się pomijać punkt, że klucz podstawowy jest częścią tabeli, a tabela jest częścią schematu. To, co jest najlepsze dla relacji table I table, powinno kierować używanym kluczem.

Tabele (i relacje tabel) zawierają fakty dotyczące informacji, które chcesz rekord. Fakty te powinny być samodzielne, znaczące, łatwe do zrozumienia i niesprzeczne. Z punktu widzenia projektu inne tabele dodane lub usunięte ze schematu nie powinny mieć wpływu na daną tabelę. Musi istnieć cel przechowywania danych związanych tylko z samą informacją. Zrozumienie tego, co jest przechowywane w tabeli, nie powinno wymagać poddania się badaniom naukowym. Żaden fakt przechowywany w tym samym celu nie powinien być przechowywany więcej niż jeden raz. Klucze są całością lub część rejestrowanych informacji jest unikalna, a klucz główny jest specjalnie wyznaczonym kluczem, który ma być głównym punktem dostępu do tabeli(tzn. powinien być wybrany dla spójności i wykorzystania danych, a nie tylko dla wydajności wstawiania).

• na bok: niestety efekt uboczny większości baz danych projektowanych i rozwijany przez programistów aplikacji (którym czasem jestem) jest że to, co jest najlepsze dla aplikacji lub frameworku aplikacji często napędza klucz główny wybór stołów. Prowadzi to do liczby całkowitej i Klucze GUID (ponieważ są one proste w użyciu dla frameworków aplikacji) oraz monolitycznych konstrukcji stołów (ponieważ zmniejszają one liczbę aplikacji obiekty framework potrzebne do reprezentowania danych w pamięci). Te decyzje projektowe baz danych oparte na aplikacjach prowadzą do powstania istotnych danych problemy z konsystencją przy stosowaniu na skalę. Ramy aplikacji zaprojektowany w ten sposób w naturalny sposób prowadzić do tabeli w czasie projektów. "Rekordy częściowe" są tworzone w tabelach i dane uzupełniane w czasie. Unika się interakcji wielostolikowych lub w przypadku użycia powoduje niespójność dane, gdy aplikacja działa nieprawidłowo. Te projekty prowadzą do danych, które są bezsensowne (lub trudne do zrozumienia), dane rozprzestrzeniają się nad stołami (trzeba spojrzeć na inne stoły, aby zrozumieć bieżącej tabeli), oraz zduplikowane dane.

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. Losowe dodawanie należy unikać bezsensownych pól do tabeli. Jeszcze gorzej jest zrobić klucz z losowo dodanego bezsensownego pola, zwłaszcza gdy niszczy ono zależność join z innej tabeli do klucza innego niż podstawowy. Jest to uzasadnione tylko wtedy, gdy nie ma dobrych kluczy kandydatów w tabeli, ale to wystąpienie jest z pewnością oznaką słabego schematu, jeśli jest używane dla wszystkich tabel.

Mówiono również, że klucze podstawowe nigdy nie powinny się zmieniać, ponieważ aktualizacja klucza podstawowego powinna być zawsze poza pytanie. Ale aktualizacja jest taka sama jak delete, a następnie insert. Zgodnie z tą logiką nigdy nie należy usuwać rekordu z tabeli za pomocą jednego klawisza, a następnie dodawać kolejny rekord za pomocą drugiego klawisza. Dodanie zastępczego klucza podstawowego nie usuwa faktu istnienia drugiego klucza w tabeli. Aktualizacja klucza innego niż podstawowy tabeli może zniszczyć znaczenie danych, jeśli inne tabele są zależne od tego znaczenia za pomocą klucza zastępczego (np. tabela statusu z kluczem zastępczym o statusie opis zmieniony z "przetworzony" na "Anulowany" zdecydowanie uszkodziłby 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ą obecnie w firmach (bez znaczenia-zastępcze-klucze-dane-uszkodzone-1NF behemoty), ponieważ oznacza to, że jest nieskończona ilość pracy dla ludzi, którzy rozumieją prawidłowe projektowanie baz danych. Ale ze smutnej strony, to czasami sprawia, że czuję się jak Syzyf, ale założę się, że miał po 401k (przed katastrofą). Trzymaj się z dala od blogów i stron internetowych, aby uzyskać ważne pytania dotyczące projektowania baz danych. Jeśli projektujesz bazy danych, poszukaj daty CJ. Możesz również odwołać się do Celko dla SQL Server, ale tylko jeśli najpierw przytrzymasz nos. Od strony wyroczni, odniesienie Tom Kyte.

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

• Wszystkie tabele powinny mieć pojedynczy klucz główny kolumny, który automatycznie przyrosty.
• Włącz 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ć SKU, numer konta, identyfikator pracownika lub inne informacje, które mają znaczenie dla Twojej aplikacji. On tylko unikalny klucz związany z podmiotem.

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

Zawsze posiadanie pojedynczej wartości klucza podstawowego sprawia, że wykonywanie operacji Upsert jest bardzo proste.

• Faworyzowanie wielu indeksów w pojedynczych kolumnach nad indeksami wielokolumnowymi.
  Na przykład, jeśli masz dwie kolumny klucz, faworyzowanie tworzenia indeksu na każdej kolumnie zamiast tworzenia indeksu dwóch kolumn. Jeśli utworzymy wielokolumnowy klucz na firstname + lastname, nie możemy zrobić zindeksowanych wyszukiwań na LastName bez podania imienia. Posiadanie indeksów w obu kolumnach umożliwia optymalizatorowi wykonywanie zindeksowanych wyszukiwań na jednej lub obu kolumnach, niezależnie od tego, jak są one wyrażone w klauzuli WHERE.

• Jeśli tabele są ogromne, zbadaj podział tabeli na segmenty w oparciu o najbardziej ważne kryteria wyszukiwania.

• Jeśli masz tabelę, która zawiera znaczną liczbę pól Id, rozważ usunięcie wszystkich z wyjątkiem klucza głównego do pojedynczej tabeli, która ma id (PK), org_id (FK do oryginalnej tabeli) i kolumnę id_type. Utwórz indeksy dla wszystkich kolumn nowej tabeli i powiązaj je z oryginalną tabelą. W ten sposób można teraz wykonywać zindeksowane wyszukiwanie dowolnej liczby identyfikatorów przy użyciu tylko jednego indeksu.

Klucz naturalny, jeśli jest dostępny, jest zwykle najlepszy. Jeśli więc datetime / char jednoznacznie identyfikuje wiersz i obie części mają dla niego znaczenie, to świetnie.

Jeśli tylko datetime ma znaczenie, a znak jest po prostu zaznaczony, aby uczynić go unikalnym, możesz równie dobrze użyć pola identyfikacji.

Naturalne kontra sztuczne klucze to dla mnie kwestia tego, ile logiki biznesowej chcesz w swojej bazie danych. Numer ubezpieczenia społecznego (SSN) jest doskonałym przykładem.

"każdy klient w mojej bazie danych będzie I musi posiadać SSN."BAM, zrobione, zrób to głównym kluczem i zrób to z nim. Pamiętaj tylko, że gdy zmieni się Twoja zasada biznesowa, jesteś spalony.

Nie lubię kluczy naturalnych, ze względu na moje doświadczenie w zmienianiu zasad biznesowych. Ale jeśli jesteś pewien, że to się nie zmieni, to może zapobiec kilku krytycznym połączeniom.

Podejrzewam, że dla projektanta oryginalnej struktury danych potrzebna jest zwinięta Gazeta Stevena A. Lowe ' a.

Na marginesie, GUIDs jako klucz podstawowy może być hog wydajności. Nie polecam.

Powinieneś użyć klucza głównego' composite 'lub' compound', który składa się z wielu pól.

Jest to całkowicie akceptowalne rozwiązanie, idź TUTAJ Po Więcej informacji:)

Ja też zawsze używam kolumny numeric ID. W oracle używam liczby (18,0) bez prawdziwego powodu powyżej liczby (12,0) (lub cokolwiek to jest int, a nie długi), może po prostu nie chcę się martwić o uzyskanie kilku miliardów wierszy w db!

Dołączam również utworzoną i zmodyfikowaną kolumnę (Typ timestamp) do podstawowego śledzenia, gdzie wydaje się przydatna.

Nie przeszkadza mi ustawianie unikalnych ograniczeń na innych kombinacjach kolumn, ale bardzo podoba mi się mój id, utworzony, zmodyfikowany baseline wymagania.

Szukam 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 do końca w drzewach.

Na tablicach, które są łącznikami wielu do wielu, używam złożonego klucza głównego kluczy obcych.

Ponieważ mam szczęście korzystać z SQL Server mogę studiować plany wykonania i statystyki z profilerem i analizatorem zapytań i dowiedzieć się, jak są moje klucze wykonując bardzo łatwo.

Zawsze używam pola autonumber lub identity.

Pracowałem dla klienta, który używał SSN jako klucza podstawowego, a następnie z powodu przepisów HIPAA został zmuszony do zmiany na "Membid" i spowodowało to 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.

GUID może być używany jako klucz podstawowy, ale musisz utworzyć odpowiedni typ GUID, aby działał dobrze.

Musisz wygenerować Comb GUID. Dobry artykuł o it i statystykach wydajności to koszt GUID jako kluczy podstawowych.

Również jakiś kod na budowanie GUID w SQL jest w Uniqueidentifier vs tożsamość(archiwum).

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

Dla tabel wyszukiwania z małą ilością wierszy, możesz 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 ty mieć tabelę referencyjną, która być może Zawiera złożony klucz podstawowy złożony z kluczy obcych z powiązanych tabel.

Jeśli naprawdę chcesz przeczytać całą tę wiekową debatę, poszukaj "naturalnego klucza" na Stack Overflow. Powinieneś wrócić do stron wyników.

Wykonujemy wiele połączeń, a kompozytowe klucze podstawowe stały się właśnie świnią wydajności. Prosty int lub long zajmuje się wieloma problemami, nawet jeśli wprowadzasz drugi klucz kandydata, ale o wiele łatwiejsze i bardziej zrozumiałe jest połączenie na jednym polu w porównaniu z trzema.

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

• Row ID (GUID)
• Creator (string; ma domyślną nazwę bieżącego użytkownika (SUSER_SNAME() W T-SQL))
• Created (DateTime)
• Timestamp

Identyfikator wiersza ma unikalny klucz w tabeli i w każdym przypadku jest automatycznie generowany dla każdego wiersza (a uprawnienia uniemożliwiają jego edycję), i ma rozsądną gwarancję, że jest unikalny we wszystkich tabelach i bazach danych. Jeśli jakikolwiek system ORM potrzebuje jednego klucza ID, jest to ten, którego należy użyć.

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

• ludzie-używają klucza zastępczego, np. INT. Jeśli jest wewnętrzny, to identyfikator GUID użytkownika usługi Active Directory jest akceptowalnym wyborem
• tabele wyszukiwania (np. StatusCodes) - użyj krótkiego kodu CHAR; jest to łatwiejsze do zapamiętania niż INTs, a w wielu przypadkach papierowe formularze i użytkownicy będą również używać go do zwięzłości (np. Status = "E" dla "Expired", "A" dla "Approved", "NADIS" dla "No azbest Detected In Sample") {]}
• łączenie tabel - kombinacja FKs (np. EventId, AttendeeId)

Najlepiej więc skończyć z naturalnym, czytelnym dla człowieka i niezapomnianym PK oraz przyjaznym dla ORM GUIDEM o jednym identyfikatorze dla każdej tabeli.

Zastrzeżenie: bazy danych, które prowadzę, mają tendencję do 100 000 rekordów, a nie milionów lub miliardy, więc jeśli masz doświadczenie z większymi systemami, które stanowią moją radę, nie krępuj się mnie ignorować!