Wenn keine Ersatz-Primärschlüssel verwendet werden sollen?

Ich würde sagen, dass die folgenden Kriterien erfüllt sein müssen:

• Ihr natürlicher Schlüssel muss absolut, positiv, ohne Ausnahmen, einzigartig sein (Dinge wie Namen, Sozialversicherungsnummern usw. scheinen normalerweise zu sein) einzigartig - aber wirklich nicht)

• Ihr natürlicher Schlüssel sollte so klein wie ein INT sein, z. nicht wesentlich mehr als 4 Bytes groß (verwenden Sie kein VARCHAR (50) für Ihre PK und insbesondere nicht für Ihren Clustering-Schlüssel in SQL Server!)

• Ihr natürlicher Schlüssel sollte stabil sein, z. niemals ändern (OK, mit ISO-Ländercodes ist das fast selbstverständlich - außer wenn Länder wie Jugoslawien oder die UdSSR kollabieren, oder andere wie die beiden Germanien sich vereinigen - aber das ist selten genug)

Wenn diese Bedingungen erfüllt sind, können Sie einen natürlichen Schlüssel als Ihre PK betrachten - aber das sollte die 2% Ausnahme in all Ihren Tabellen sein - nicht die Norm.

Ich bin mir nicht sicher, ob es einen Ausnahmefall gibt, wenn Ersatzschlüssel nicht verwendet werden sollten . Ich denke, dass die Art eines Ersatzschlüssels, im Allgemeinen um einen Verweis global einzigartig zu machen, besonders relevant ist, wenn er auf ein System angewendet wird, wie Sie es beschreiben.

Obwohl jeder der von Ihnen genannten Satelliten-Primärschlüssel innerhalb seines eigenen Bereichs eindeutig sein kann, können Sie nicht wirklich garantieren, dass sie im gesamten Umfang Ihrer verbundenen Umgebung eindeutig bleiben, insbesondere wenn sie erweitert wird. Ich vermute, dass die ursprünglichen Designer entweder versuchten, ihr System zukunftssicher zu machen oder die neueste Mode, die sie gelernt hatten, zu fahren;)

Natürliche Schlüssel (Ländercodes in Ihrem Fall) sind besser, weil

• sie machen Sinn, wenn Sie sie sehen (Ersatzschlüssel allein bedeutet nichts für den Benutzer. Dies ist wichtig für die DB-Entwickler und Betreuer, die oft mit unformatierten DB-Ausgaben arbeiten müssen)
• weniger Joins (oft benötigen Sie nur den Ländercode und sie sind bereits in anderen Tabellen. Wenn Sie Ersatzschlüssel verwenden, müssen Sie der Nachschlagetabelle beitreten)

Der Nachteil der natürlichen Schlüssel ist, dass sie an die Informationslogik gebunden sind, und wenn sie sich ändert (was manchmal passiert), müssen Sie viele Tabellen ändern und einen wesentlichen Teil der DB grundlegend überarbeiten.

Wenn Sie also in Ihrer Datenbank die Logik für viele Jahre nicht ändern, verwenden Sie natürliche Schlüssel.

Es gibt eine lange Debatte darüber. Wenn Sie nach "surrogate v natural keys" suchen, erhalten Sie viele Links. Ich vermute also, dass Sie hier eher eine Debatte als eine klare Antwort bekommen werden.

Aus diesem Artikel :

  

Datenmodellierer (für diese Diskussion schließe ich jeden ein, der Tabellen für eine Datenbank entworfen hat) sind in dieser Frage geteilter Meinung: Einige Modellierer schwören auf den Ersatzschlüssel; Andere würden sterben, bevor sie irgendetwas anderes als einen natürlichen Schlüssel benutzten. Eine Suche in der Literatur über Datenmodellierung und Datenbankdesign unterstützt keine Seite außer im Data Warehouse-Bereich, in dem ein Ersatzschlüssel die einzige Wahl für Dimensions- und Faktentabellen ist.

Zusätzlich zu dem, was marc_s sagte, brauchen Sie in der Regel keinen Surrgogate-Schlüssel in einer Verknüpfungstabelle, die eine Tabelle ist, die nur zwei verschiedene Primärschlüssel enthält, die zum Erstellen von Viele-zu-Viele-Beziehungen verwendet werden. Im Allgemeinen funktioniert hier ein zusammengesetzter Schlüssel für beide Felder. Dies ist einer der wenigen Male, die ich einen zusammengesetzten Schlüssel vorschlage, im Allgemeinen bevorzuge ich einen Ersatzschlüssel und einen eindeutigen Index für den zusammengesetzten Schlüssel.

Die Verwendung von natürlichen Schlüsseln zu Identifikationszwecken ist eine gute Idee, wenn natürliche Schlüssel wirklich vertrauenswürdig sind. Siehe Marc_S Antwort für einige Fälle, in denen natürliche Schlüssel nicht vertrauenswürdig sind. Sorgen Sie sich nicht zu sehr um Effizienz. Selbst etwas wie die VIN (Vehicle Identification Number) wird Ihre Datenbank nicht sehr nach unten ziehen. Wenn Sie denken, dass dies der Fall ist, machen Sie ein paar Tests und stellen Sie fest, dass die Effizienz nicht linear skaliert.

Der Hauptgrund für die Deklaration eines Primärschlüssels besteht darin, zu verhindern, dass eine Tabelle aus der ersten Normalform herausrutscht und dadurch keine Relation mehr darstellt. Die Verwendung eines automatisch inkrementierten Ersatzschlüssels kann zu zwei Zeilen mit unterschiedlichen ID-Feldern führen, die jedoch ansonsten identisch sind. Dies bringt Ihnen einige der Probleme, die mit Daten einhergehen, die nicht in der ersten normalen Form vorliegen. Und die Benutzer können nicht helfen, weil sie das ID-Feld nicht sehen können.

Wenn die Zeilen einer Tabelle durch eine Kombination von zwei oder mehr Fremdschlüsseln bestimmt werden können, haben Sie eine Beziehungstabelle, die manchmal als Verknüpfungstabelle oder Junction-Tabelle bezeichnet wird. Normalerweise ist es besser, einen zusammengesetzten Primärschlüssel zu deklarieren, der aus allen benötigten Fremdschlüsseln besteht.

Wenn die obigen Optionen zu einer langsamen Leistung führen, kann dies manchmal durch Erstellen einiger zusätzlicher Indizes behoben werden. Es hängt davon ab, was Sie mit den Daten machen.