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

Surrogatschlüssel (in der Regel Ganzzahlen) haben den zusätzlichen Vorteil, dass sie Ihre Tabellenbeziehungen schneller machen und wirtschaftlicher in Bezug auf die Speicher- und Aktualisierungsgeschwindigkeit sind (noch besser: Fremdschlüssel müssen bei der Verwendung von Surrogatschlüsseln nicht aktualisiert werden, im Gegensatz zu Geschäftsschlüsselfeldern, die sich hin und wieder ändern).

Der Primärschlüssel einer Tabelle sollte zur eindeutigen Identifizierung der Zeile verwendet werden, hauptsächlich für Verknüpfungszwecke. Denken Sie an eine Personentabelle: Namen können sich ändern, und sie sind nicht garantiert eindeutig.

Denken Sie an Unternehmen: Sie sind ein glückliches Merkin-Unternehmen, das mit anderen Unternehmen in Merkia Geschäfte macht. Sie sind klug genug, nicht den Firmennamen als Primärschlüssel zu verwenden, sondern die eindeutige Firmen-ID der Regierung von Merkia in ihrer Gesamtheit von 10 alphanumerischen Zeichen. Dann ändert Merkia die Unternehmens-IDs, weil sie es für eine gute Idee hielten. Das ist in Ordnung, Sie verwenden die Funktion für kaskadierte Aktualisierungen Ihrer Datenbankmaschine für eine Änderung, die Sie gar nicht betreffen sollte. Später expandiert Ihr Unternehmen, und Sie arbeiten nun mit einem Unternehmen in Freedonia zusammen. Freedonische Firmen-IDs bestehen aus bis zu 16 Zeichen. Sie müssen den Primärschlüssel der Firmenkennung erweitern (auch die Fremdschlüsselfelder in Bestellungen, Ausgaben, Überweisungen usw.) und ein Feld "Land" in den Primärschlüssel aufnehmen (auch in die Fremdschlüssel). Autsch! Bürgerkrieg in Freedonia, es ist in drei Länder aufgeteilt. Der Name des Landes, mit dem Sie verbunden sind, sollte in den neuen Namen geändert werden; kaskadierte Aktualisierungen sind die Rettung. Übrigens, was ist Ihr Primärschlüssel? (Land, FirmenID) oder (FirmenID, Land)? Letzteres hilft bei Joins, ersteres vermeidet einen weiteren Index (oder vielleicht mehrere, wenn Sie Ihre Bestellungen auch nach Ländern gruppieren wollen).

All dies ist kein Beweis, sondern ein Hinweis darauf, dass ein Surrogatschlüssel zur eindeutigen Identifizierung einer Zeile für alle Verwendungszwecke, einschließlich Join-Operationen, einem Geschäftsschlüssel vorzuziehen ist.

Answer 2

Ich möchte meine Erfahrung mit Ihnen auf diesem endlosen Krieg teilen :D auf natürlichem gegen Leihmutterschaft Schlüssel Dilemma. Ich denke, dass beide Surrogatschlüssel (künstliche, automatisch generierte Schlüssel) und natürliche Schlüssel (bestehend aus Spalten mit Domänenbedeutung) haben Profis y Nachteile . Je nach Situation kann es also sinnvoller sein, die eine oder die andere Methode zu wählen.

Da es scheint, dass viele Leute Ersatzschlüssel als die fast perfekte Lösung und natürliche Schlüssel als die Pest darstellen, werde ich mich auf die Argumente der anderen Sichtweise konzentrieren:

Nachteile von Surrogatschlüsseln

Surrogatschlüssel sind:

1. Quelle der Leistungsprobleme:
   • Sie werden in der Regel mit automatisch inkrementierten Spalten implementiert, was bedeutet:
     • Jedes Mal, wenn Sie eine neue Kennung abrufen wollen, müssen Sie einen Roundtrip zur Datenbank machen (ich weiß, dass dies durch Caching oder [seq]hilo-ähnliche Algorithmen verbessert werden kann, aber auch diese Methoden haben ihre eigenen Nachteile).
     • Wenn Sie eines Tages Ihre Daten von einem Schema in ein anderes verschieben müssen (was zumindest in meinem Unternehmen recht häufig vorkommt), könnten Sie auf Kollisionsprobleme stoßen. Und ja, ich weiß, dass man UUIDs verwenden kann, aber diese benötigen 32 hexadezimale Ziffern! (Wenn Ihnen die Größe der Datenbank wichtig ist, kann das ein Problem sein).
     • Wenn Sie eine Sequenz für alle Ihre Ersatzschlüssel verwenden, wird es in Ihrer Datenbank mit Sicherheit zu Konflikten kommen.
2. Fehleranfällig. Eine Sequenz hat eine max_value-Grenze, so dass Sie als Entwickler auf die folgenden Punkte achten müssen:
   • Sie müssen Ihre Sequenz zyklisch ablaufen lassen (wenn der Maximalwert erreicht ist, geht es zurück zu 1,2,...).
   • Wenn Sie die Sequenz als Ordnung (über die Zeit) Ihrer Daten verwenden, müssen Sie den Fall des Zyklus behandeln (Spalte mit Id 1 könnte neuer sein als Zeile mit Id max-value - 1).
   • Stellen Sie sicher, dass Ihr Code (und sogar Ihre Client-Schnittstellen, was nicht passieren sollte, da es sich um eine interne Id handeln soll) 32b/64b-Ganzzahlen unterstützt, die Sie zum Speichern Ihrer Sequenzwerte verwenden.
3. Sie garantieren nicht, dass die Daten nicht dupliziert werden. Sie können immer 2 Zeilen mit denselben Spaltenwerten haben, aber mit einem anderen generierten Wert. Für mich ist das DIE Problem der Ersatzschlüssel aus der Sicht des Datenbankdesigns.
4. Mehr in Wikipedia...

Mythen über natürliche Schlüssel

1. Zusammengesetzte Schlüssel sind weniger ineffizient als Surrogatschlüssel. Nein! Das hängt von der verwendeten Datenbank-Engine ab:
   • Oracle
   • MySQL
2. Natürliche Schlüssel gibt es im wirklichen Leben nicht. Tut mir leid, aber es gibt sie! In der Luftfahrtindustrie zum Beispiel ist das folgende Tupel in Bezug auf einen bestimmten Wert immer eindeutig geplant Flug (Fluggesellschaft, Abflugdatum, Flugnummer, operationalSuffix). Allgemeiner ausgedrückt, wenn ein Satz von Geschäftsdaten garantiert eindeutig ist durch einen bestimmten Standard dann ist dieser Datensatz ein [guter] natürlicher Schlüsselkandidat.
3. Natürliche Schlüssel "verschmutzen das Schema" der untergeordneten Tabellen. Für mich ist dies eher ein Gefühl als ein echtes Problem. Ein vierspaltiger Primärschlüssel mit je 2 Byte könnte effizienter sein als eine einzige Spalte mit 11 Byte. Außerdem können die 4 Spalten verwendet werden, um die untergeordnete Tabelle direkt abzufragen (indem die 4 Spalten in einer Where-Klausel verwendet werden), ohne eine Verbindung zur übergeordneten Tabelle herzustellen.

Schlussfolgerung

Verwenden Sie natürliche Schlüssel, wenn es sinnvoll ist, und Ersatzschlüssel, wenn es besser ist.

Ich hoffe, dass dies jemandem geholfen hat!

Answer 3

Verwenden Sie immer einen Schlüssel, der keine geschäftliche Bedeutung hat. Das ist einfach gute Praxis.

EDIT: Ich habe versucht, einen Link dazu online zu finden, aber ich konnte es nicht. Allerdings in Muster der Unternehmensarchitektur". [Fowler] gibt es eine gute Erklärung, warum man nichts anderes als einen Schlüssel verwenden sollte, der keine andere Bedeutung hat, als ein Schlüssel zu sein. Es läuft auf die Tatsache hinaus, dass er eine Aufgabe und nur eine Aufgabe haben sollte.

Answer 4

Surrogat-Schlüssel sind recht praktisch, wenn Sie planen, ein ORM-Tool zur Bearbeitung/Erzeugung Ihrer Datenklassen zu verwenden. Sie können zwar zusammengesetzte Schlüssel mit einigen der fortschrittlicheren Mappern (z. B. Hibernate) verwenden, doch wird Ihr Code dadurch etwas komplexer.

(Natürlich werden Datenbankpuristen argumentieren, dass sogar die Vorstellung eines Ersatzschlüssels eine Abscheulichkeit ist).

Ich bin ein Fan der Verwendung von UIDs als Ersatzschlüssel, wenn sie geeignet sind. Der große Vorteil bei ihnen ist, dass Sie den Schlüssel im Voraus kennen, z. B. können Sie eine Instanz einer Klasse mit der ID bereits festgelegt und garantiert eindeutig sein, während mit, sagen wir, ein Integer-Schlüssel müssen Sie standardmäßig auf 0 oder -1 und aktualisieren Sie auf einen geeigneten Wert, wenn Sie speichern / aktualisieren.

UIDs haben jedoch Nachteile in Bezug auf die Such- und Verbindungsgeschwindigkeit, so dass es von der jeweiligen Anwendung abhängt, ob sie wünschenswert sind.

Answer 5

Die Verwendung eines Ersatzschlüssels ist meiner Meinung nach besser, da er sich nicht ändern kann. Fast alles, was ich mir vorstellen kann, was Sie als natürlichen Schlüssel verwenden könnten, könnte sich ändern (Haftungsausschluss: nicht immer wahr, aber häufig).

Ein Beispiel wäre eine DB von Autos - auf den ersten Blick könnte man meinen, dass das Nummernschild als Schlüssel verwendet werden könnte. Da diese aber geändert werden können, wäre das eine schlechte Idee. Das möchten Sie nicht wirklich herausfinden. nach die App freizugeben, wenn jemand zu Ihnen kommt und wissen will, warum er sein Nummernschild nicht gegen sein neues, personalisiertes austauschen kann.