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

Dies sind nur einige Gründe für die Verwendung von Ersatzschlüsseln:

1. Stabilität : Die Änderung eines Schlüssels aufgrund einer geschäftlichen oder natürlichen Notwendigkeit wirkt sich negativ auf die zugehörigen Tabellen aus. Surrogatschlüssel müssen selten, wenn überhaupt, geändert werden, da der Wert keine Bedeutung hat.

2. Konvention : Ermöglicht es Ihnen, eine standardisierte Konvention für die Benennung von Primärschlüsselspalten zu haben, anstatt sich Gedanken darüber machen zu müssen, wie man Tabellen mit verschiedenen Namen für ihre PKs verbindet.

3. Geschwindigkeit : Je nach PK-Wert und -Typ kann ein Surrogatschlüssel aus einer ganzen Zahl kleiner sein und sich schneller indizieren und durchsuchen lassen.

Answer 2

Beides. Du kannst deinen Kuchen essen.

Denken Sie daran, dass ein Primärschlüssel nichts Besonderes ist, außer dass er als solcher gekennzeichnet ist. Er ist nichts anderes als eine NOT NULL UNIQUE-Beschränkung, und eine Tabelle kann mehr als eine haben.

Wenn Sie einen Surrogatschlüssel verwenden, benötigen Sie dennoch einen Geschäftsschlüssel, um die Eindeutigkeit gemäß den Geschäftsregeln zu gewährleisten.

Answer 3

Es scheint, dass noch niemand etwas zur Unterstützung von Nicht-Surrogat-Schlüsseln (ich zögere, "natürlich" zu sagen) gesagt hat. Also hier geht's los...

A Nachteil von Ersatzschlüsseln ist, dass sie bedeutungslos (von einigen als Vorteil angeführt, aber...). Dies zwingt Sie manchmal dazu, viel mehr Tabellen in Ihre Abfrage einzubinden, als eigentlich nötig wäre. Vergleichen Sie:

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

gegen:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

Es sei denn, jemand hält das Folgende ernsthaft für eine gute Idee:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"Aber", wird jemand sagen, "was passiert, wenn sich der Code für MYPROJECT oder VALID oder HR ändert?" Darauf würde ich antworten: "Warum sollten Sie 必要 um sie zu ändern?" Es handelt sich nicht um "natürliche" Schlüssel in dem Sinne, dass irgendeine äußere Instanz vorschreibt, dass von nun an "GÜLTIG" in "GUT" umcodiert werden soll. Nur ein kleiner Prozentsatz der "natürlichen" Schlüssel fällt wirklich in diese Kategorie - SSN und Postleitzahl sind die üblichen Beispiele. Ich würde auf jeden Fall einen bedeutungslosen numerischen Schlüssel für Tabellen wie "Person" und "Adresse" verwenden - aber nicht für alles was aus irgendeinem Grund die meisten Leute hier zu befürworten scheinen.

Siehe auch: meine Antwort auf eine andere Frage

Answer 4

Ich hasse Ersatzschlüssel im Allgemeinen. Sie sollten nur verwendet werden, wenn kein hochwertiger natürlicher Schlüssel verfügbar ist. Es ist ziemlich absurd, wenn man darüber nachdenkt, dass das Hinzufügen von bedeutungslosen Daten zu Ihrer Tabelle die Dinge besser machen könnte.

Hier sind meine Gründe:

1. Bei der Verwendung von natürlichen Schlüsseln werden die Tabellen so geclustert, dass sie am häufigsten durchsucht werden, wodurch die Abfragen schneller werden.

2. Bei der Verwendung von Surrogatschlüsseln müssen Sie eindeutige Indizes auf Spalten mit logischen Schlüsseln hinzufügen. Sie müssen dennoch logische Datenduplikate verhindern. Sie können zum Beispiel nicht zwei Organisationen mit demselben Namen in Ihrer Organisationstabelle zulassen, obwohl die pk-Spalte eine Surrogat-id-Spalte ist.

3. Wenn Surrogatschlüssel als Primärschlüssel verwendet werden, ist es viel weniger klar, was die natürlichen Primärschlüssel sind. Bei der Entwicklung wollen Sie wissen, welche Spalten die Tabelle eindeutig machen.

4. In ein-zu-vielen-Beziehungsketten, den logischen Schlüsselketten. So haben beispielsweise Organisationen viele Konten und Konten haben viele Rechnungen. Der logische Schlüssel der Organisation ist also OrgName. Der logische Schlüssel von Accounts ist OrgName, AccountID. Der logische Schlüssel einer Rechnung ist OrgName, AccountID, InvoiceNumber.

   Bei der Verwendung von Ersatzschlüsseln werden die Schlüsselketten verkürzt, indem nur ein Fremdschlüssel zum unmittelbar übergeordneten Schlüssel vorhanden ist. Die Tabelle Invoice hat zum Beispiel keine Spalte OrgName. Sie verfügt nur über eine Spalte für die AccountID. Wenn Sie nach Rechnungen für eine bestimmte Organisation suchen möchten, müssen Sie die Tabellen "Organisation", "Konto" und "Rechnung" verknüpfen. Wenn Sie logische Schlüssel verwenden, können Sie die Tabelle Organisation direkt abfragen.

5. Die Speicherung von Surrogatschlüsselwerten in Nachschlagetabellen führt dazu, dass die Tabellen mit bedeutungslosen ganzen Zahlen gefüllt werden. Um die Daten anzuzeigen, müssen komplexe Ansichten erstellt werden, die sich mit allen Nachschlagetabellen verbinden. Eine Nachschlagetabelle ist dazu gedacht, eine Reihe von akzeptablen Werten für eine Spalte zu speichern. Sie sollte nicht kodifiziert werden, indem stattdessen ein Integer-Surrogatschlüssel gespeichert wird. In den Normalisierungsregeln gibt es keinen Hinweis darauf, dass Sie einen Surrogat-Ganzzahlwert anstelle des eigentlichen Wertes speichern sollten.

6. Ich habe drei verschiedene Datenbankbücher. In keinem von ihnen wird die Verwendung von Surrogatschlüsseln beschrieben.

Answer 5

Die Leihmutterschaft wird NIE einen Grund haben, sich zu ändern. Das kann ich von den natürlichen Schlüsseln nicht behaupten. Nachnamen, E-Mails, ISBN-Nummern - sie alle können sich eines Tages ändern.