Surrogatschlüssel vs. natürliche/geschäftliche Schlüssel

Question

Da haben wir es wieder, das alte Argument taucht immer noch auf...

Wäre es besser, einen Geschäftsschlüssel als Primärschlüssel zu verwenden, oder sollten wir lieber eine Ersatzkennung (d. h. eine SQL Server-Identität) mit einer eindeutigen Einschränkung für das Geschäftsschlüsselfeld verwenden?

Bitte geben Sie Beispiele oder Beweise an, um Ihre Theorie zu untermauern.

Answer 1

Fall 1: Ihr Tisch ist ein Nachschlagetabelle mit weniger als 50 Datensätzen (50 Typen)

Verwenden Sie in diesem Fall manuell benannte Schlüssel, entsprechend der Bedeutung der einzelnen Datensätze .

Zum Beispiel:

Table: JOB with 50 records
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

---

Fall 2: Ihr Tisch ist ein Tabelle mit Tausenden von Datensätzen

Utilice Surrogat-/Autoinkrementschlüssel .

Zum Beispiel:

Table: ASSIGNMENT with 1000000 records
joined with
Table: PEOPLE with 100000 records

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

---

Im ersten Fall:

• Sie können alle Programmierer in der Tabelle auswählen PEOPLE ohne Verwendung der Verknüpfung mit der Tabelle JOB , sondern nur mit: SELECT * FROM PEOPLE WHERE JOBCODE = 'PRG'

Im zweiten Fall:

• Ihre Datenbankabfragen sind schneller, weil Ihr Primärschlüssel eine ganze Zahl ist.
• Sie brauchen sich nicht um die Suche nach dem nächsten eindeutigen Schlüssel zu kümmern, denn die Datenbank selbst gibt Ihnen das nächste Autoinkrement vor.

Answer 2

Verwenden Sie, wenn möglich, immer einen einspaltigen Ersatzschlüssel. Dadurch werden Verknüpfungen sowie Einfügungen/Aktualisierungen/Löschungen viel sauberer, da Sie nur für die Verfolgung einer einzigen Information zur Pflege des Datensatzes verantwortlich sind.

Stapeln Sie dann je nach Bedarf Ihre geschäftlichen Schlüssel als eindeutige Beschränkungen oder Indizes. Auf diese Weise bleibt die Datenintegrität gewahrt.

Geschäftslogik/natürliche Schlüssel können sich ändern, aber der physikalische Schlüssel einer Tabelle sollte sich NIEMALS ändern.

Answer 3

In einem Datawarehouse-Szenario ist es meines Erachtens besser, den Weg des Surrogatschlüssels zu gehen. Aus zwei Gründen:

• Sie sind unabhängig vom Quellsystem, und Änderungen dort - z. B. eine Änderung des Datentyps - haben keine Auswirkungen auf Sie.
• Ihre DW benötigt weniger physischen Speicherplatz, da Sie nur ganzzahlige Datentypen für Ihre Surrogatschlüssel verwenden werden. Auch Ihre Indizes werden besser funktionieren.

Answer 4

Ersatzschlüssel können nützlich sein, wenn sich Geschäftsinformationen ändern oder identisch sein können. Unternehmensnamen müssen schließlich nicht im ganzen Land eindeutig sein. Angenommen, Sie haben mit zwei Unternehmen namens Smith Electronics zu tun, eines in Kansas und eines in Michigan. Sie können sie anhand der Adresse unterscheiden, aber die wird sich ändern. Sogar der Staat kann sich ändern; was ist, wenn Smith Electronics aus Kansas City, Kansas, über den Fluss nach Kansas City, Missouri, zieht? Es gibt keine offensichtliche Möglichkeit, diese Unternehmen mit natürlichen Schlüsselinformationen auseinanderzuhalten, daher ist ein Ersatzschlüssel sehr nützlich.

Stellen Sie sich den Surrogatschlüssel wie eine ISBN-Nummer vor. Normalerweise identifiziert man ein Buch nach Titel und Autor. Ich habe jedoch zwei Bücher mit dem Titel "Pearl Harbor" von H. P. Willmott, und es handelt sich definitiv um verschiedene Bücher, nicht nur um verschiedene Ausgaben. In einem solchen Fall könnte ich mich auf das Aussehen der Bücher beziehen, oder auf das frühere gegenüber dem späteren, aber es ist genauso gut, dass ich auf die ISBN zurückgreifen kann.

Answer 5

Dies ist einer der Fälle, in denen ein Ersatzschlüssel ziemlich genau siempre macht Sinn. Es gibt Fälle, in denen Sie sich entweder für das entscheiden, was für die Datenbank oder für Ihr Objektmodell am besten ist, aber in beiden Fällen ist die Verwendung eines bedeutungslosen Schlüssels oder einer GUID die bessere Idee. Er macht die Indizierung einfacher und schneller, und er ist eine Identität für Ihr Objekt, die sich nicht ändert.