Ersatz- / Natur- / Geschäftsschlüssel [geschlossen]

173

Jetzt geht es wieder los, das alte Argument taucht immer noch auf ...

Würden wir besser einen Geschäftsschlüssel als Primärschlüssel haben, oder hätten wir lieber eine Ersatz-ID (dh eine SQL Server-Identität) mit einer eindeutigen Einschränkung für das Geschäftsschlüsselfeld?

Bitte geben Sie Beispiele oder Beweise an, um Ihre Theorie zu stützen.

Manrico Corazzi
quelle
24
@ Joachim Sauer: Ein Argument darüber, ob eine Sache subjektiv ist, kann selbst subjektiv sein, ohne dass dies in irgendeiner Weise mit der Objektivität oder Subjektivität der fraglichen Sache zusammenhängt. Es sei denn, Sie sind bereit, die genauen objektiven Kriterien anzugeben, die etwas objektiv machen. Es gibt Dinge, die als "offene Konzepte" bezeichnet werden, z. B. wie viele Haare für die Herstellung eines Bartes erforderlich sind. Man kann objektiv sagen, dass eine Person ohne Kinnhaar keinen Bart hat und eine Person mit 5.000 Haaren, die einen Zentimeter lang ist, einen Bart hat, aber irgendwo in der Mitte ist ein subjektives Urteil erforderlich, um eine objektive Bestimmung zu treffen.
ErikE
@Manrico: Sie müssen sich nur Folgendes fragen: Wenn ich keinen Ersatzschlüssel verwende, ist mein Primärschlüssel dann immer noch unveränderlich? Wenn die Antwort Nein lautet, sollten Sie ernsthaft in Betracht ziehen, einen Ersatzschlüssel zu verwenden. Wenn der Primärschlüssel auch nur teilweise aus Benutzereingaben besteht, sollten Sie die Verwendung eines Ersatzschlüssels in Betracht ziehen. Warum? Wegen der Gefahr von Datenanomalien.
Code4life
@ TylerRick Aber das ist keine ganz gute Frage. Es wird nach einer Lösung gefragt, die allgemein auf alle Situationen anwendbar ist, in denen es eindeutig keine gibt, wie der "Religionskrieg" beweist, dessen sich der Fragesteller vollkommen bewusst ist (Zitat: "Jetzt geht es wieder los, das alte Argument taucht immer noch auf. .. "). Anstatt sich zu fragen, ob sich die Welt verändert hat und schließlich ein zwingender Grund angegeben wurde, immer eine Seite zu wählen, ist es besser, diese Frage für jede konkrete Situation immer wieder zu stellen und bei SO zu posten, wenn Sie sich nicht sicher sind . Dies löst nur Dogmatismus aus.
MarioDS

Antworten:

96

Beide. Haben Sie Ihren Kuchen und essen Sie ihn.

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

Wenn Sie einen Ersatzschlüssel verwenden, möchten Sie dennoch einen Geschäftsschlüssel, um die Eindeutigkeit gemäß den Geschäftsregeln sicherzustellen.

Ted
quelle
7
Wenn Sie mehrere "Kandidaten" -Schlüssel haben (Felder oder gleich große Sammlungen von Feldern, die NICHT NULL EINZIGARTIG sind), verstoßen Sie wahrscheinlich gegen die Boyce-Codd-Normalform. BCNF ist jenseits von 3NF, daher machen sich nicht viele Menschen darüber Sorgen. Es gibt jedoch Situationen, in denen es sehr hilfreich ist, in BCNF zu sein.
Alan
2
Einverstanden. Die eigentliche Frage sollte lauten: Soll ich meinen Tabellen einen eindeutigen Ersatzschlüssel hinzufügen? Eine ganz andere Frage ist, was für einen logischen Primärschlüssel verwendet werden soll. Sie sind beide im Wesentlichen nur eindeutige Indexbeschränkungen ungleich Null.
Dkretz
1
"Jedes Problem wird mit einer anderen Indirektionsebene gelöst" ... Ersatzschlüssel sind genau das: eine andere Indirektionsebene
Steve Schnepp
5
Ich finde es seltsam, dass viele Kommentare zu behaupten scheinen, dass man ohne einen Ersatzschlüssel keine Beziehung aufbauen kann. In vielen Fällen ist der Ersatzschlüssel überflüssig. Warum etwas hinzufügen, das keinen Wert bringt, aber technische Schulden hinzufügt (und in einigen Fällen dazu führt, dass ein ansonsten einzigartiges Ergebnis plötzlich nicht mehr eindeutig wird)?
Wil Moore III
2
Es ist mehr als eine NOT NULL UNIQUE-Einschränkung. Der Primärschlüssel wird als Clustered-Index verwendet, der die physische Reihenfolge Ihrer Daten bestimmt. Im Allgemeinen ist Integer leicht zu balancieren, da es nacheinander inkrementiert wird und Ihre Daten an die EOF auf der Festplatte angehängt werden. Wenn Sie weniger sequentielle Daten wie Text oder GUID (UUID) verwenden, wird es viel mehr Festplatten-E / A und mehr Aufwand geben, um den Index auszugleichen. Ich denke, das ist ein großer Unterschied
Jin
124

Nur einige Gründe für die Verwendung von Ersatzschlüsseln:

  1. Stabilität : Das Ändern eines Schlüssels aufgrund eines geschäftlichen oder natürlichen Bedarfs wirkt sich negativ auf verwandte Tabellen aus. Ersatzschlüssel müssen selten, wenn überhaupt, geändert werden, da mit dem Wert keine Bedeutung verbunden ist.

  2. Konvention : Ermöglicht eine standardisierte Namenskonvention für Primärschlüsselspalten, anstatt darüber nachdenken zu müssen, wie Tabellen mit verschiedenen Namen für ihre PKs verknüpft werden.

  3. Geschwindigkeit : Abhängig vom PK-Wert und -Typ kann ein Ersatzschlüssel einer Ganzzahl kleiner sein und schneller indiziert und gesucht werden.

Jay Shepherd
quelle
2
Nachdem ich viel über Ersatzschlüssel und natürliche Schlüssel gelesen habe, denke ich, dass die Verwendung von Ersatzschlüsseln besser ist. In meiner Datenbank müssen natürliche Schlüssel (ein NVARCHAR (20)) jedoch eindeutig sein. Ich verstehe nicht, wie ich mehr Geschwindigkeit erreichen kann, wenn ich alle Daten in dieser Spalte überprüfen muss, um keinen Wert (unter Verwendung einer NOT NULL UNIQUE-Einschränkung) für jede Einfügung zu wiederholen.
VansFannel
70

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

Ein Nachteil von Ersatzschlüsseln ist, dass sie bedeutungslos sind (von einigen als Vorteil angeführt, aber ...). Dies zwingt Sie manchmal dazu, viel mehr Tabellen in Ihre Abfrage einzubinden, als wirklich notwendig sein sollte. 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 ernsthaft Folgendes 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" jemand wird sagen, "was passiert, wenn sich der Code für MYPROJECT oder VALID oder HR ändert?" Welchem meine Antwort wäre: „Warum würden Sie brauchen , um es zu ändern?“ Dies sind keine "natürlichen" Schlüssel in dem Sinne, dass eine externe Stelle gesetzlich festlegen wird, dass "GÜLTIG" von nun an als "GUT" umcodiert werden sollte. 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 definitiv einen bedeutungslosen numerischen Schlüssel für Tabellen wie Person, 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

Tony Andrews
quelle
14
-1 Natürliche Schlüssel als Primärschlüssel haben das Problem, dass Sie für jede untergeordnete Tabelle den übergeordneten Schlüssel hinzufügen müssen, der aus mehr als einem Feld bestehen kann (anstelle von nur einem, was bei einem Ersatzschlüssel der Fall ist) und auch das untergeordnete Schlüssel. Stellen Sie sich also Folgendes vor, wobei ausgehend von TABLEA die Beziehung 1-0 ist. *: TABLEA PK: ID_A TABLEB PK: ID_A ID_B TABLEC PK: ID_A ID_B ID_C TABLED PK: ID_A ID_B ID_C ID_D. Sehen Sie das Problem? Der übergeordnete Schlüssel wird in den untergeordneten Tabellen weitergegeben. Was würde passieren, wenn sich der Primärschlüssel von TABLEA ändert? Jetzt müssten Sie auch alle untergeordneten Tabellen PK umgestalten.
Alfredo Osorio
9
@ Alfredo: Ja natürlich gibt es einen Kompromiss. In meiner mehr als 20-jährigen Erfahrung habe ich jedoch selten die Definition der PK-Änderung einer Tabelle gesehen. Wenn es regelmäßig passieren würde, würde ich wahrscheinlich auch natürliche Schlüssel vermeiden. In der Realität bin ich in den äußerst seltenen Fällen, in denen dies passiert, bereit, den Treffer des erweiterten Aufpralls zu ertragen.
Tony Andrews
10
Ich bin nicht einverstanden. Es ist häufig der Fall, wenn eine externe Stelle (der Kunde) vorschreibt, dass ein natürlicher Schlüssel bearbeitet und daher im gesamten System verbreitet werden muss. Ich sehe das regelmäßig. Sie können nur dann sicher sein, dass sich der Schlüssel nie ändern muss, wenn er per Definition bedeutungslos ist. Darüber hinaus verarbeiten moderne Datenbanken innere Verknüpfungen äußerst effizient, sodass der potenziell große Platzgewinn durch die Verwendung von Ersatzverknüpfungen in der Regel den Vorteil überwiegt, dass nicht so viele innere Verknüpfungen durchgeführt werden müssen.
TTT
8
@TTT: Dann war das Design zunächst schwach. Auch hier trennen sich die Männer von den Jungen: Sie treffen die richtige Wahl, wann der natürliche Schlüssel verwendet werden soll und wann ein Ersatz verwendet werden soll. Sie entscheiden dies auf Tabellenbasis, nicht als allgemeines Dogma.
DanMan
7
Ich habe auch mehr als 20 Jahre Erfahrung und stimme Ihrer Meinung zu. Ich habe einmal ein Oracle Datawarehouse mit Ersatzschlüsseln erstellt, und die Datenpflege war höllisch. Sie können einfach nie direkt auf Ihre Daten zugreifen. Sie müssen immer Abfragen für alles schreiben, und das macht es einfach schrecklich, Ersatzschlüssel zu handhaben.
SQL Police
31

Der Ersatzschlüssel hat NIEMALS einen Grund zur Änderung. Ich kann nicht dasselbe über die natürlichen Schlüssel sagen. Nachnamen, E-Mails, ISBN-Nummern - alle können sich eines Tages ändern.

Rimantas
quelle
31

Ersatzschlüssel (normalerweise Ganzzahlen) haben den Mehrwert, dass Ihre Tabellenbeziehungen schneller und wirtschaftlicher in Bezug auf Speicher- und Aktualisierungsgeschwindigkeit sind (noch besser, Fremdschlüssel müssen bei der Verwendung von Ersatzschlüsseln im Gegensatz zu Geschäftsschlüsselfeldern nicht aktualisiert werden.) das ändert sich ab und zu).

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

Think Companies: Sie sind ein glückliches Merkin-Unternehmen, das mit anderen Unternehmen in Merkia Geschäfte macht. Sie sind klug genug, den Firmennamen nicht als Primärschlüssel zu verwenden, und verwenden daher die eindeutige Firmen-ID der Regierung von Merkia in ihrer Gesamtheit von 10 alphanumerischen Zeichen. Dann ändert Merkia die Firmen-IDs, weil sie dachten, es wäre eine gute Idee. Es ist in Ordnung, Sie verwenden die kaskadierte Update-Funktion Ihrer Datenbank-Engine für eine Änderung, die Sie nicht an erster Stelle einbeziehen sollte. Später expandiert Ihr Geschäft und jetzt arbeiten Sie mit einem Unternehmen in Freedonia zusammen. Die freedonische Firmen-ID besteht aus bis zu 16 Zeichen. Sie müssen den Primärschlüssel der Unternehmens-ID (auch die Fremdschlüsselfelder in Bestellungen, Ausgaben, Geldtransfers usw.) vergrößern und im Primärschlüssel (auch in den Fremdschlüsseln) ein Länderfeld hinzufügen. Autsch! Bürgerkrieg in Freedonia, es ' s in drei Länder aufgeteilt. Der Ländername Ihres Mitarbeiters sollte in den neuen Namen geändert werden. kaskadierte Updates zur Rettung. Übrigens, was ist Ihr Primärschlüssel? (Land, Firmen-ID) oder (Firmen-ID, Land)? Letzteres hilft beim Beitritt, Ersteres vermeidet einen anderen Index (oder vielleicht viele, falls Sie möchten, dass Ihre Bestellungen auch nach Ländern gruppiert werden).

All dies ist kein Beweis, aber ein Hinweis darauf, dass ein Ersatzschlüssel zur eindeutigen Identifizierung einer Zeile für alle Verwendungszwecke, einschließlich Verknüpfungsvorgängen, einem Geschäftsschlüssel vorzuziehen ist.

tzot
quelle
Sie gewinnen alle Internets mit dem coolsten Benutzernamen!
Iain Holder
1
Das ist so ziemlich das, was eine Ablehnung ist: "Dem stimme ich nicht zu."
JCollum
5
Der Tooltip des Abwärtspfeils lautet "Diese Antwort ist nicht nützlich", nicht "Ich stimme dem nicht zu". Vielleicht sind in dieser spezifischen Antwort die Bedeutungen nahe beieinander, aber sie sind im Allgemeinen nicht gleich.
tzot
1
Wenn jemand denkt, dass Ihre Antwort falsch ist, wird er (/ sie) auch denken, dass dies den Fragesteller in die falsche Richtung führt (entgegen der richtigen Richtung), und wird Ihre Antwort daher als noch schlechter als "nicht hilfreich" beurteilen. Rechtfertigung in seinem (/ ihrem) Kopf eine Ablehnung.
Erwin Smout
1
Ja, Ersatzschlüssel sind eine Krankheit. Einer leckt in die Wildnis und Sie verwenden ihn als Schlüssel, sodass Sie jetzt Ihren eigenen Ersatzschlüssel benötigen. Dann leckt Ihr Schlüssel in die Wildnis (etwa durch eine URL) und die Krankheit breitet sich aus.
Samuel Danielson
25

Ich hasse Ersatzschlüssel im Allgemeinen. Sie sollten nur verwendet werden, wenn kein natürlicher Qualitätsschlüssel verfügbar ist. Es ist ziemlich absurd, wenn Sie darüber nachdenken, dass das Hinzufügen bedeutungsloser Daten zu Ihrer Tabelle die Dinge verbessern könnte.

Hier sind meine Gründe:

  1. Bei Verwendung natürlicher Schlüssel werden Tabellen so gruppiert, wie sie am häufigsten durchsucht werden, wodurch Abfragen schneller werden.

  2. Wenn Sie Ersatzschlüssel verwenden, müssen Sie eindeutige Indizes für logische Schlüsselspalten hinzufügen. Sie müssen weiterhin logische doppelte Daten verhindern. Beispielsweise können Sie nicht zwei Organisationen mit demselben Namen in Ihrer Organisationstabelle zulassen, obwohl das pk eine Ersatz-ID-Spalte ist.

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

  4. In einer bis vielen Beziehungsketten die logischen Schlüsselketten. So haben Organisationen beispielsweise viele Konten und Konten viele Rechnungen. Der logische Schlüssel der Organisation ist also OrgName. Der logische Schlüssel von Accounts ist OrgName, AccountID. Der logische Schlüssel von Invoice ist OrgName, AccountID, InvoiceNumber.

    Wenn Ersatzschlüssel verwendet werden, werden die Schlüsselketten abgeschnitten, indem nur ein Fremdschlüssel für das unmittelbare übergeordnete Element vorhanden ist. Beispielsweise enthält die Rechnungstabelle keine OrgName-Spalte. Es gibt nur eine Spalte für die AccountID. Wenn Sie nach Rechnungen für eine bestimmte Organisation suchen möchten, müssen Sie den Tabellen Organisation, Konto und Rechnung beitreten. Wenn Sie logische Schlüssel verwenden, können Sie die Organisationstabelle direkt abfragen.

  5. Durch das Speichern von Ersatzschlüsselwerten von Nachschlagetabellen werden Tabellen mit bedeutungslosen Ganzzahlen gefüllt. Um die Daten anzuzeigen, müssen komplexe Ansichten erstellt werden, die mit allen Nachschlagetabellen verknüpft sind. Eine Nachschlagetabelle soll eine Reihe akzeptabler Werte für eine Spalte enthalten. Es sollte nicht durch Speichern eines ganzzahligen Ersatzschlüssels codiert werden. Die Normalisierungsregeln enthalten keine Hinweise darauf, dass Sie anstelle des Werts selbst eine Ersatz-Ganzzahl speichern sollten.

  6. Ich habe drei verschiedene Datenbankbücher. Keiner von ihnen zeigt die Verwendung von Ersatzschlüsseln.

Ken
quelle
7
Ich hasse Ersatzschlüssel, außer wenn sie notwendig sind. Sie sind erforderlich, wenn das Unternehmen einen natürlichen Schlüssel verwendet, der vielen Fehlern unterliegt, und nicht bereit ist, eine Datenbank zu tolerieren, die von diesen Fehlern betroffen ist.
Walter Mitty
26
-1: Ich habe Dutzende von Bewerbungen geschrieben und gepflegt. Diejenigen mit den meisten datenbezogenen Problemen waren diejenigen, die natürliche Schlüssel verwendeten.
Falcon
6
Einige Ihrer Punkte gehen davon aus, dass der Ersatzschlüssel die PK oder die gruppierte Spalte sein muss - nicht wahr. Ihre Punkte 1 und 5 ignorieren die Tatsache, dass Ganzzahlen 4 Bytes und natürliche Schlüssel fast immer viele, viel mehr Bytes sind. Und jeder nicht gruppierte Index muss die Bytes der natürlichen Schlüssel wiederholen, die sich im gruppierten Index befinden, sodass die Tabellen und Indizes in Ihrer Datenbank für natürliche Schlüssel weitaus weniger Zeilen pro Seite enthalten, was zu einer viel schlechteren Leseleistung führt Dies macht Abfragen langsamer und nicht schneller.
ErikE
3
Ein weiterer Grund für natürliche Schlüssel (Beispiele: Ordnungszahlen, VINs usw.) ist, dass sich die Geschäftslogik ändern kann, wodurch sich der Datentyp erhöht. Zum Beispiel - Vorher: Nachverfolgen von Gebühren für Atome, Nachher: ​​Nachverfolgen von Gebühren von Atomen und Verbindungen. Vorher: Verfolgung von Kraftfahrzeugen auf Tragfähigkeit. Nachher: ​​Hinzufügen von Flugzeugen, Booten, Fahrrädern und Personen zur Tragfähigkeit.
Forforf
3
Ich denke, Sie haben keine Tabellen, in denen der Primärschlüssel auch nur teilweise aus 1) Attributen besteht, die sich ändern können und werden) oder 2) aus Benutzereingaben (z. B. dynamisch generierten Suchlisten). Wenn Sie die Unveränderlichkeit von Schlüsseln nicht garantieren können, müssen Sie alle diese Entitätsbeziehungen durch Code oder manuelle "Fix" -Skripte aktualisieren. Wenn Sie das nie tun mussten ... Ich denke, Ihre Datenbank ist sowohl ohne Schlüssel als auch ... ungewöhnlich.
Code4life
18

Ich möchte meine Erfahrungen in diesem endlosen Krieg mit Ihnen teilen: D über das natürliche und das Ersatzschlüsseldilemma. Ich denke, dass sowohl Ersatzschlüssel (künstliche automatisch generierte) als auch natürliche Schlüssel (bestehend aus Spalten mit Domänenbedeutung) Vor- und Nachteile haben . Abhängig von Ihrer Situation kann es daher relevanter sein, die eine oder andere Methode zu wählen.

Da es den Anschein hat, dass viele Menschen Ersatzschlüssel als nahezu perfekte Lösung und natürliche Schlüssel als Pest darstellen, werde ich mich auf die Argumente des anderen Gesichtspunkts konzentrieren:

Nachteile von Ersatzschlüsseln

Ersatzschlüssel sind:

  1. Ursache für Leistungsprobleme:
    • Sie werden normalerweise mit automatisch inkrementierten Spalten implementiert, die Folgendes bedeuten:
      • Ein Roundtrip zur Datenbank jedes Mal, wenn Sie eine neue ID erhalten möchten (ich weiß, dass dies mithilfe von Caching- oder [seq] hilo-ähnlichen Algorithmen verbessert werden kann, aber diese Methoden haben immer noch ihre eigenen Nachteile).
      • Wenn Sie eines Tages Ihre Daten von einem Schema in ein anderes verschieben müssen (dies kommt zumindest in meinem Unternehmen regelmäßig vor), können Probleme mit der ID-Kollision auftreten. Und ja, ich weiß, dass Sie UUIDs verwenden können, aber diese Leisten erfordern 32 hexadezimale Ziffern! (Wenn Sie sich für die Datenbankgröße interessieren, kann dies ein Problem sein).
      • Wenn Sie eine Sequenz für alle Ihre Ersatzschlüssel verwenden, kommt es mit Sicherheit zu Konflikten in Ihrer Datenbank.
  2. Fehleranfällig. Eine Sequenz hat ein max_value-Limit, daher müssen Sie als Entwickler die folgenden Punkte beachten:
    • Sie müssen Ihre Sequenz durchlaufen (wenn der Maximalwert erreicht ist, geht er zurück auf 1,2, ...).
    • Wenn Sie die Sequenz als Reihenfolge (über die Zeit) Ihrer Daten verwenden, müssen Sie den Fall des Zyklus behandeln (Spalte mit der ID 1 ist möglicherweise neuer als die Zeile mit der ID max-value - 1).
    • Stellen Sie sicher, dass Ihr Code (und sogar Ihre Client-Schnittstellen, die nicht als interne ID verwendet werden sollten) 32b / 64b-Ganzzahlen unterstützt, die Sie zum Speichern Ihrer Sequenzwerte verwendet haben.
  3. Sie garantieren keine nicht duplizierten Daten. Sie können immer 2 Zeilen mit denselben Spaltenwerten, jedoch mit einem anderen generierten Wert haben. Für mich ist dies DAS Problem der Ersatzschlüssel aus Sicht des Datenbankdesigns.
  4. Mehr in Wikipedia ...

Mythen über natürliche Schlüssel

  1. Zusammengesetzte Schlüssel sind weniger ineffizient als Ersatzschlüssel. Nein! Dies hängt vom verwendeten Datenbankmodul ab:
  2. Natürliche Schlüssel existieren im wirklichen Leben nicht. Entschuldigung, aber sie existieren! In der Luftfahrtindustrie beispielsweise ist das folgende Tupel für einen bestimmten Linienflug (Fluggesellschaft, Abflugdatum, Flugnummer, Betriebssuffix) immer eindeutig . Im Allgemeinen ist dieser Datensatz ein [guter] natürlicher Schlüsselkandidat , wenn ein Satz von Geschäftsdaten nach einem bestimmten Standard garantiert eindeutig ist.
  3. Natürliche Schlüssel "verschmutzen das Schema" von untergeordneten Tabellen. Für mich ist das eher ein Gefühl als ein echtes Problem. Ein Primärschlüssel mit 4 Spalten und jeweils 2 Bytes ist möglicherweise effizienter als eine einzelne Spalte mit 11 Bytes. 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 sich der übergeordneten Tabelle anzuschließen.

Fazit

Verwenden Sie natürliche Schlüssel, wenn dies relevant ist, und verwenden Sie Ersatzschlüssel, wenn es besser ist, sie zu verwenden.

Hoffe das hat jemandem geholfen!

mwnsiri
quelle
3
Was passiert, wenn das Abflugdatum des Linienfluges verschoben wird? Müssen Sie alle zugehörigen Entitäten aufspüren und die Schlüssel löschen, oder aktualisieren Sie tatsächlich alle Schlüssel in den zugehörigen Entitäten? Oder haben Sie es mit einer einfachen, singulären Tabelle zu tun (möglicherweise nicht einmal 3NF)?
Code4life
Hervorragender Punkt @ Code4life
Forcewill
@ code4life: Hier springt das OperationalSuffix ins Spiel. Um die gleiche Flugnummer beizubehalten, damit wir keine Verwirrung bei den Kunden haben, fügen wir nur ein Suffix hinzu (z. B. 'D').
Mwnsiri
"Sie können immer 2 Zeilen mit denselben Spaltenwerten, aber mit einem anderen generierten Wert haben". Legen Sie also einfach eine eindeutige oder zusammengesetzte eindeutige Einschränkung für Ihre Spalten fest.
immer,
15

Verwenden Sie immer einen Schlüssel, der keine geschäftliche Bedeutung hat. Es ist nur eine gute Übung.

EDIT: Ich habe versucht, online einen Link dazu zu finden, konnte es aber nicht. In 'Patterns of Enterprise Archtecture' [Fowler] finden Sie jedoch eine gute Erklärung dafür, warum Sie nichts anderes als einen Schlüssel verwenden sollten, der keine andere Bedeutung hat als ein Schlüssel zu sein. Es läuft darauf hinaus, dass es nur einen Job und nur einen Job haben sollte.

Iain Holder
quelle
22
Martin Fowler mag vieles sein, aber er ist keine Autorität im Datenbankdesign.
Tony Andrews
Ich denke, Sie sollten einige Überlegungen anstellen, bevor Sie zu dem Schluss kommen.
Arne Evertsson
4
@ArneEvertsoon Der Grund ist da drin. "Es läuft darauf hinaus, dass es nur einen Job und nur einen Job haben sollte." Einzelverantwortung.
Iain Holder
10

Ersatzschlüssel sind sehr praktisch, wenn Sie ein ORM-Tool zum Behandeln / Generieren Ihrer Datenklassen verwenden möchten. Während Sie zusammengesetzte Schlüssel mit einigen der fortgeschritteneren Mapper (sprich: Ruhezustand) verwenden können, erhöht dies die Komplexität Ihres Codes.

(Natürlich werden Datenbank-Puristen argumentieren, dass selbst die Vorstellung eines Ersatzschlüssels ein Greuel ist.)

Ich bin ein Fan von Uids für Ersatzschlüssel, wenn dies geeignet ist. Der größte Vorteil bei ihnen ist, dass Sie den Schlüssel im Voraus kennen, z. B. eine Instanz einer Klasse erstellen können, deren ID bereits festgelegt und garantiert eindeutig ist, während Sie beispielsweise bei einem Ganzzahlschlüssel standardmäßig 0 oder - verwenden müssen 1 und aktualisieren Sie auf einen geeigneten Wert, wenn Sie speichern / aktualisieren.

UIDs haben jedoch Nachteile hinsichtlich der Suche und der Verbindungsgeschwindigkeit. Daher hängt es von der jeweiligen Anwendung ab, ob sie wünschenswert sind.

Derek Lawless
quelle
6

Die Verwendung eines Ersatzschlüssels ist meiner Meinung nach besser, da keine Wahrscheinlichkeit besteht, dass sich dieser ändert. 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 könnte eine DB von Autos sein - auf den ersten Blick könnte man denken, dass das Nummernschild als Schlüssel verwendet werden könnte. Aber diese könnten geändert werden, so dass das eine schlechte Idee wäre. Sie möchten das nach der Veröffentlichung der App nicht wirklich herausfinden , wenn jemand zu Ihnen kommt und wissen möchte, warum er sein Nummernschild nicht in sein glänzendes neues personalisiertes ändern kann.

Mark Embling
quelle
1
Leider haben Autos einen natürlichen Schlüssel, der sich nicht ändert: die Fahrgestellnummer (zumindest in Amerika ...)
jcollum
@jcollum Ja ok, das ist ein fairer Punkt. Meine Meinung bleibt jedoch bestehen, mein Beispiel war nicht unbedingt so gut wie es sein könnte.
Mark Embling
2
Eine Liste von Sprachen wäre ein Beispiel für einen natürlichen Schlüssel, wenn Sie ihn auf ISO-Codes basieren. Wenn Sie dann Inhalte aus einer Tabelle in einer bestimmten Sprache laden möchten, müssen Sie sich nicht an der languagesTabelle beteiligen, da der Sprachcode (ID) bereits in der textsTabelle enthalten ist.
DanMan
@ DanMan Da muss ich dir zustimmen. Es wird immer einige Beispiele geben, die mit einem natürlichen Schlüssel besser funktionieren. Regeln oder gemeinsame Ansätze sind niemals absolut, und das ist ein Beispiel, das ich zu 100% für Ihren Ansatz verwenden würde :-)
Mark Embling
5

Verwenden Sie nach Möglichkeit immer einen einspaltigen Ersatzschlüssel. Dies macht Verknüpfungen sowie Einfügungen / Aktualisierungen / Löschungen viel sauberer, da Sie nur für die Verfolgung einer einzelnen Information verantwortlich sind, um den Datensatz zu verwalten.

Stapeln Sie dann nach Bedarf Ihre Geschäftsschlüssel als eindeutige Einschränkungen oder Indizes. Dadurch bleibt die Datenintegrität erhalten.

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

user7658
quelle
4

In einem Datawarehouse-Szenario ist es meines Erachtens besser, dem Ersatzschlüsselpfad zu folgen. Zwei Gründe:

  • Sie sind unabhängig vom Quellsystem, und Änderungen dort - wie z. B. eine Änderung des Datentyps - wirken sich nicht auf Sie aus.
  • Ihr DW benötigt weniger physischen Speicherplatz, da Sie nur ganzzahlige Datentypen für Ihre Ersatzschlüssel verwenden. Auch Ihre Indizes funktionieren besser.
Santiago Cepas
quelle
2

Ersatzschlüssel können nützlich sein, wenn sich Geschäftsinformationen ändern oder identisch sein können. Schließlich müssen Firmennamen nicht landesweit eindeutig sein. Angenommen, Sie haben mit zwei Unternehmen namens Smith Electronics zu tun, einem in Kansas und einem in Michigan. Sie können sie nach Adresse unterscheiden, aber das 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 anhand natürlicher Schlüsselinformationen voneinander zu unterscheiden. Daher ist ein Ersatzschlüssel sehr nützlich.

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

David Thornley
quelle
1
Ich denke, ich muss Ihrem Beispiel hier nicht zustimmen. Eine ISBN-Nummer ist ein Attribut eines Buches. Ein Ersatzschlüssel ist unabhängig von den übrigen Zeilendaten. Daher würde diese Position die Verwendung eines separaten Ersatzschlüssels für eine Buchtabelle empfehlen, obwohl die ISBN jedes Buch bereits eindeutig identifiziert.
Christopher Cashell
Stellen Sie sich die ISBN alternativ als Ersatzschlüssel vor. Es ist eine Kennung ohne Bedeutung, nur ein Code, der auf ein bestimmtes Buch angewendet wird. Wenn Sie eine Büchertabelle erstellen, kann die ISBN auch der Primärschlüssel sein (vorausgesetzt, Sie haben und haben immer ein Buch pro Zeile).
David Thornley
@Christopher Cashell - Kam über diesen Beitrag von vor einem Jahr, aber ich dachte, etwas hinzuzufügen. ISBNs sind garantiert nicht eindeutig und können Duplikate enthalten. Ich habe einen Freund, der mehrere Jahre in einer Bibliothek gearbeitet hat und der häufig auf Bücher mit doppelten ISBN gestoßen ist. Das Problem ist, dass die Einzigartigkeit der ISBN dem Verlag obliegt und nicht einer Stelle, die sicherstellt, dass alle Nummern für alle Veröffentlichungen gelten sind einzigartig und diese Verlage hatten nicht immer ihre Handlung zusammen.
Thomas
2
Kam über diesen Beitrag von vor einem Jahr und wollte erwähnen, dass ISBN in der Tat natürliche Schlüssel sind. Im Gegensatz zu einem Ersatzschlüssel ist im Schlüsselwert selbst eine Bedeutung eingebrannt. Ein Teil des Schlüssels identifiziert beispielsweise den Herausgeber. Darüber hinaus ist, wie oben erwähnt, nicht garantiert, dass sie einzigartig sind. Sie sollen einzigartig sein, aber diese Einzigartigkeit kommt von den Verlagen und sie waren nicht immer perfekt.
Thomas
Technisch gesehen können sich Unternehmen nicht zwischen Staaten bewegen. Was passiert ist, dass eine neue Gesellschaft im neuen Staat gegründet wird und das Vermögen übertragen wird. Das funktioniert auch für Datenbankinformationen.
Warren Dew
2

Zur Erinnerung: Es wird nicht empfohlen, Clustered-Indizes auf zufälligen Ersatzschlüsseln zu platzieren, dh auf GUIDs, die XY8D7-DFD8S lesen, da SQL Server diese Daten nicht physisch sortieren kann. Sie sollten stattdessen eindeutige Indizes für diese Daten platzieren. Es kann jedoch auch von Vorteil sein, einfach den SQL-Profiler für die Haupttabellenoperationen auszuführen und diese Daten dann in den Database Engine Tuning Advisor zu platzieren.

Siehe Thread @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be

Bryan Swan
quelle
Ich bin mir ziemlich sicher, dass SQL Server GUIDs sortieren kann .
Michael Green
Dies ist nicht genau, obwohl sie die GUID auswerten können, ist die resultierende Sortierung für einen Menschen nicht unsinnig. stackoverflow.com/questions/7810602/…
Bryan Swan
1
Eine wahre Aussage, aber ganz anders als "SQL Server kann diese nicht physisch sortieren."
Michael Green
2

Fall 1: Ihre Tabelle ist eine Nachschlagetabelle mit weniger als 50 Typen (Einfügungen).

Verwenden Sie Business / Natural Keys . Beispielsweise:

Table: JOB with 50 inserts
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: Ihre Tabelle ist eine Tabelle mit Tausenden von Einfügungen

Verwenden Sie Ersatz- / Autoincrement-Schlüssel . Beispielsweise:

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

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 PEOPLE auswählen, ohne die Verknüpfung mit der Tabelle JOB zu verwenden, aber nur mit: "SELECT * FROM PEOPLE WHERE JOBCODE = 'PRG'"

Im zweiten Fall:

  • Ihre Datenbankabfragen sind schneller, da Ihr Primärschlüssel eine Ganzzahl ist
  • Sie müssen sich nicht darum kümmern, den nächsten eindeutigen Schlüssel zu finden, da die Datenbank selbst Ihnen die nächste automatische Inkrementierung ermöglicht.
Stefanos Kargas
quelle
2

Dies ist einer der Fälle, in denen ein Ersatzschlüssel so gut wie immer Sinn macht. Es gibt Fälle, in denen Sie entweder auswählen, was für die Datenbank am besten ist oder was für Ihr Objektmodell am besten ist. In beiden Fällen ist es jedoch besser, einen bedeutungslosen Schlüssel oder eine GUID zu verwenden. Dies erleichtert und beschleunigt die Indizierung und ist eine Identität für Ihr Objekt, die sich nicht ändert.

Charles Graham
quelle
1

Pferd für Kurse. Um meine Voreingenommenheit auszudrücken; Ich bin zuerst Entwickler, daher geht es mir hauptsächlich darum, den Benutzern eine funktionierende Anwendung zu bieten.

Ich habe an Systemen mit natürlichen Schlüsseln gearbeitet und musste viel Zeit darauf verwenden, sicherzustellen, dass sich Wertänderungen bemerkbar machen.

Ich habe an Systemen mit nur Ersatzschlüsseln gearbeitet, und der einzige Nachteil war das Fehlen denormalisierter Daten für die Partitionierung.

Die meisten traditionellen PL / SQL-Entwickler, mit denen ich zusammengearbeitet habe, mochten Ersatzschlüssel aufgrund der Anzahl der Tabellen pro Join nicht, aber unsere Test- und Produktionsdatenbanken haben nie ins Schwitzen gebracht. Die zusätzlichen Verknüpfungen hatten keinen Einfluss auf die Anwendungsleistung. Bei Datenbankdialekten, die keine Klauseln wie "X inner join Y on Xa = Yb" unterstützen, oder bei Entwicklern, die diese Syntax nicht verwenden, erschweren die zusätzlichen Joins für Ersatzschlüssel das Ablesen der Abfragen und das Schreiben von und länger check: siehe @ Tony Andrews Beitrag. Wenn Sie jedoch ein ORM oder ein anderes SQL-Generierungsframework verwenden, werden Sie es nicht bemerken. Touch-Typing mildert auch.

Werde sehen
quelle
Ebenfalls; Wenn Sie wirklich nach Hause fahren möchten, dass die Ersatzschlüssel genau das sind, starten Sie sie mit einer großen Zufallszahl und erhöhen Sie die Sequenzen um 3+ anstatt um 1. Oder verwenden Sie dieselbe Sequenz, um Werte für mehr als einen Schlüssel zu generieren.
WillC
1

Vielleicht nicht ganz relevant für dieses Thema, aber Kopfschmerzen, die ich mit Ersatzschlüsseln habe. Von Oracle vorab bereitgestellte Analysen erstellen automatisch generierte SKs für alle Dimensionstabellen im Warehouse und speichern diese auch anhand der Fakten. Jedes Mal, wenn sie (Dimensionen) neu geladen werden müssen, wenn neue Spalten hinzugefügt werden, oder wenn sie für alle Elemente in der Dimension ausgefüllt werden müssen, werden die SKs aufgrund der während der Aktualisierung zugewiesenen SKs nicht mehr mit den ursprünglichen Werten synchronisiert, die für die Tatsache gespeichert sind, und erzwingen dies ein vollständiges Neuladen aller Faktentabellen, die damit verbunden sind. Ich würde es vorziehen, selbst wenn der SK eine bedeutungslose Zahl wäre, würde es eine Möglichkeit geben, dass er sich für ursprüngliche / alte Datensätze nicht ändern könnte. Wie viele wissen, erfüllt Out-of-the-Box selten die Anforderungen eines Unternehmens, und wir müssen uns ständig anpassen. Wir haben jetzt Daten im Wert von 3 Jahren in unserem Lager. Das vollständige Nachladen aus den Oracle Financial-Systemen ist sehr umfangreich. In meinem Fall werden sie also nicht aus der Dateneingabe generiert, sondern in einem Warehouse hinzugefügt, um die Berichtsleistung zu verbessern. Ich verstehe, aber unsere ändern sich und es ist ein Albtraum.

lrb
quelle
0

Bei einer Zeitpunktdatenbank ist es am besten, eine Kombination aus Ersatz- und natürlichen Schlüsseln zu verwenden. Sie müssen beispielsweise die Informationen eines Mitglieds für einen Club verfolgen. Einige Attribute eines Mitglieds ändern sich nie. zB Geburtsdatum, aber Name kann sich ändern. Erstellen Sie also eine Member-Tabelle mit einem Ersatzschlüssel member_id und haben Sie eine Spalte für DOB. Erstellen Sie eine weitere Tabelle mit dem Namen Personenname und haben Sie Spalten für member_id, member_fname, member_lname, date_updated. In dieser Tabelle wäre der natürliche Schlüssel member_id + date_updated.


quelle