it-swarm-eu.dev

Surrogate vs. Natural / Business Keys

Hier geht es wieder los, der alte Streit taucht immer noch auf ...

Hätten wir besser einen Geschäftsschlüssel als Primärschlüssel oder hätten wir lieber eine Ersatz-ID (d. H. Eine SQL Server-Identität) mit einer eindeutigen Einschränkung für das Geschäftsschlüsselfeld?

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

163
Manrico Corazzi

Beide. Nimm deinen Kuchen und iss 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.

91
Ted

Nur ein paar 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 zugehörige Tabellen aus. Ersatzschlüssel müssen selten, wenn überhaupt, geändert werden, da der Wert keine Bedeutung hat.

  2. Konvention: Ermöglicht eine standardisierte Namenskonvention für Primärschlüsselspalten, anstatt über das Verknüpfen von Tabellen mit verschiedenen Namen für ihre PKs nachdenken zu müssen.

  3. Geschwindigkeit: Abhängig vom PK-Wert und -Typ kann ein Ersatzschlüssel einer Ganzzahl kleiner und schneller zu indizieren und zu suchen sein.

113
Jay Shepherd

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

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 aufzunehmen, als wirklich notwendig sein sollten. 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';

Sofern niemand ernsthaft denkt, dass Folgendes eine gute Idee ist:

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?" Auf welche würde ich antworten: "Warum würdest du brauchen es ändern?" Dies sind keine "natürlichen" Schlüssel in dem Sinne, dass einige externe Stellen festlegen, dass "GÜLTIG" von nun an als "GUT" neu codiert werden soll. Nur ein kleiner Prozentsatz von "natürlichen" Schlüsseln 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

67
Tony Andrews

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

29
Rimantas

Ersatzschlüssel (in der Regel ganze Zahlen) bieten den Mehrwert, dass Ihre Tabellenbeziehungen schneller und in Bezug auf Speicherplatz und Aktualisierungsgeschwindigkeit wirtschaftlicher werden. das ändert sich ab und zu).

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 sind nicht garantiert eindeutig.

Think Companies: Sie sind eine glückliche Merkin-Firma, die mit anderen Unternehmen in Merkia Geschäfte macht. Sie sind schlau genug, den Firmennamen nicht als Primärschlüssel zu verwenden, also verwenden Sie die eindeutige Firmen-ID der Regierung von Merkia in ihrer Gesamtheit aus 10 alphanumerischen Zeichen. Dann ändert Merkia die Firmen-IDs, weil sie es für eine gute Idee hielten. Es ist in Ordnung, dass Sie die kaskadierte Update-Funktion Ihrer Datenbank-Engine verwenden, um eine Änderung vorzunehmen, die Sie eigentlich nicht betreffen sollte. Später expandiert Ihr Geschäft und Sie arbeiten jetzt bei einer Firma in Freedonia. Freedonische Firmen-ID sind bis zu 16 Zeichen. Sie müssen den Primärschlüssel der Firmen-ID (auch die Fremdschlüsselfelder in Orders, Issues, MoneyTransfers usw.) vergrößern und im Primärschlüssel (auch in den Fremdschlüsseln) ein Feld Country hinzufügen. Autsch! Der Bürgerkrieg in Freedonia ist in drei Länder aufgeteilt. Der Ländername Ihres Mitarbeiters sollte in den neuen geändert werden. kaskadierte Updates zur Rettung. Übrigens, was ist Ihr Primärschlüssel? (Land, FirmenID) oder (FirmenID, Land)? Letzteres hilft beim Beitritt, Ersteres vermeidet einen anderen Index (oder vielleicht viele, falls Sie Ihre Bestellungen auch nach Ländern gruppieren möchten).

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

29
tzot

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 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 von natürlichen Schlüsseln werden Tabellen so gruppiert, wie sie am häufigsten durchsucht werden, wodurch Abfragen beschleunigt werden.

  2. Bei Verwendung von Ersatzschlüsseln müssen Sie eindeutige Indizes für logische Schlüsselspalten hinzufügen. Sie müssen weiterhin logische Duplikate verhindern. Beispielsweise können Sie nicht zwei Organisationen mit demselben Namen in Ihrer Organisationstabelle zulassen, obwohl 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 einzigartig machen.

  4. In einer bis vielen Beziehungsketten die logischen Schlüsselketten. So verfügen beispielsweise Organisationen über viele Konten und Konten über viele Rechnungen. Der logische Schlüssel von Organization 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 den unmittelbaren übergeordneten Schlüssel vorhanden ist. Beispielsweise hat 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 ganzen Zahlen 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. Sie sollte nicht durch Speichern eines ganzzahligen Ersatzschlüssels codiert werden. Die Normalisierungsregeln enthalten keine Hinweise darauf, dass Sie anstelle des eigentlichen Werts eine ganzzahlige Ersatzzahl speichern sollten.

  6. Ich habe drei verschiedene Datenbankbücher. Keiner von ihnen verwendet Ersatzschlüssel.

26
Ken

Ich möchte meine Erfahrungen in diesem endlosen Krieg mit Ihnen teilen: D über das Dilemma zwischen natürlichen und Ersatzschlüsseln. Ich denke, dass sowohl Ersatzschlüssel (künstliche automatisch generierte) als auch natürliche Schlüssel (bestehend aus Spalte (n) mit Domänenbedeutung) haben Vor- und Nachteile . Je nach 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 die nahezu perfekte Lösung und natürliche Schlüssel als die Plage präsentieren, werde ich mich auf die Argumente der anderen Sichtweise konzentrieren:

Nachteile von Ersatzschlüsseln

Ersatzschlüssel sind:

  1. Quelle für Leistungsprobleme:
    • Sie werden normalerweise mithilfe von automatisch inkrementierten Spalten implementiert, die Folgendes bedeuten:
      • Ein Rundgang durch die Datenbank, wenn Sie eine neue ID abrufen möchten (ich weiß, dass dies mithilfe von Caching- oder 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 (zumindest in meinem Unternehmen ist dies häufig der Fall), können Probleme mit der Kollision von IDs auftreten. Und ja, ich weiß, dass Sie UUIDs verwenden können, aber diese letzten 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, werden Sie mit Sicherheit Konflikte in Ihrer Datenbank haben.
  2. Fehleranfällig. Eine Sequenz hat ein maximales Wertlimit, 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 (im Laufe der Zeit) Ihrer Daten verwenden, müssen Sie den Fall des Radfahrens behandeln (Spalte mit ID 1 ist möglicherweise neuer als Zeile mit ID max-Wert - 1).
    • Stellen Sie sicher, dass Ihr Code (und sogar Ihre Client-Schnittstellen, die nicht als interne ID auftreten 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 von Ersatzschlüsseln aus Sicht des Datenbankdesigns.
  4. Mehr in Wikipedia ...

Mythen über natürliche Schlüssel

  1. Verbundschlüssel sind weniger ineffizient als Ersatzschlüssel. Nein! Dies hängt von der verwendeten Datenbank-Engine ab:
  2. Natürliche Schlüssel existieren im wirklichen Leben nicht. Sorry, aber es gibt sie! In der Luftfahrtindustrie ist beispielsweise der folgende Tupel für einen bestimmten geplanten Flug (Fluggesellschaft, Abflugdatum, Flugnummer, Betriebs-Suffix) immer eindeutig. Im Allgemeinen ist diese Datenmenge ein [guter] natürlicher Schlüsselkandidat, wenn garantiert ist, dass eine Gruppe von Geschäftsdaten durch einen bestimmten Standard eindeutig ist.
  3. Natürliche Schlüssel "belasten das Schema" von untergeordneten Tabellen. Für mich ist das eher ein Gefühl als ein echtes Problem. Ein 4-Spalten-Primärschlüssel mit 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 der übergeordneten Tabelle beizutreten.

Fazit

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

Hoffe, dass dies jemandem geholfen hat!

17
mwnsiri

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

EDIT: Ich habe versucht, einen Link online zu finden, aber ich konnte nicht. In 'Patterns of Enterprise Archtecture' [Fowler] finden Sie jedoch eine gute Erklärung, 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 geben sollte.

15
Iain Holder

Ersatzschlüssel sind sehr praktisch, wenn Sie ein ORM-Tool zum Verarbeiten/Generieren Ihrer Datenklassen verwenden möchten. Sie können zusammengesetzte Schlüssel mit einigen der fortgeschritteneren Zuordnungen verwenden (lesen Sie: Ruhezustand), aber dies erhöht 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 angebracht ist. Der Hauptgewinn bei ihnen ist, dass Sie den Schlüssel im Voraus kennen, z. Sie können eine Instanz einer Klasse mit der ID erstellen, die bereits festgelegt und garantiert eindeutig ist. Wenn Sie beispielsweise einen Ganzzahlschlüssel verwenden, müssen Sie standardmäßig 0 oder -1 festlegen und beim Speichern/Aktualisieren auf einen geeigneten Wert aktualisieren.

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

9
Derek Lawless

Die Verwendung eines Ersatzschlüssels ist meiner Meinung nach besser, da keine Chance besteht, dass er sich ä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 gewöhnlich).

Ein Beispiel könnte eine DB mit Autos sein - auf den ersten Blick könnte man meinen, 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 würden das nicht wirklich herausfinden wollen nach Veröffentlichung der App, wenn jemand zu Ihnen kommt, der wissen möchte, warum er sein Nummernschild nicht in sein glänzendes neues personalisiertes ändern kann.

6
Mark Embling

Verwenden Sie nach Möglichkeit immer einen einspaltigen Ersatzschlüssel. Dadurch werden Verknüpfungen sowie Einfügungen/Aktualisierungen/Löschungen wesentlich übersichtlicher, da Sie nur für die Verfolgung einer einzelnen Information zur Pflege des Datensatzes verantwortlich sind.

Stapeln Sie dann Ihre Geschäftsschlüssel nach Bedarf als eindeutige Bedingungen oder Indizes. Auf diese Weise 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.

5
user7658

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

  • Sie sind unabhängig vom Quellsystem, und Änderungen dort - wie etwa 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 werden besser funktionieren.
4
Santiago Cepas

Dies ist einer jener Fälle, in denen ein Ersatzschlüssel so ziemlich immer Sinn macht. In einigen Fällen wählen Sie entweder das Beste für die Datenbank oder das Beste für Ihr Objektmodell aus. In beiden Fällen ist es jedoch besser, einen bedeutungslosen Schlüssel oder GUID zu verwenden. Dies erleichtert und vereinfacht die Indizierung schneller, und es ist eine Identität für Ihr Objekt, die sich nicht ändert.

2
Charles Graham

Zur Erinnerung, es ist keine gute Praxis, Clustered-Indizes auf zufälligen Ersatzschlüsseln zu platzieren, d. H. 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 nützlich sein, einfach den SQL-Profiler für die Haupttabellenoperationen auszuführen und diese Daten dann in den Datenbankoptimierungsratgeber zu stellen.

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

2
Bryan Swan

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

Verwenden Sie Geschäfts-/natürliche Schlüssel. 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-Tasten. 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 Ihnen die Datenbank selbst den nächsten automatischen Schritt ermöglicht.
2
Stefanos Kargas

Ersatzschlüssel können nützlich sein, wenn sich Geschäftsinformationen ändern können oder identisch sind. Firmennamen müssen schließlich nicht landesweit eindeutig sein. Angenommen, Sie arbeiten mit zwei Unternehmen namens Smith Electronics zusammen, 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 wäre, wenn Smith Electronics aus Kansas City, Kansas, über den Fluss nach Kansas City, Missouri ziehen würde? Es gibt keine offensichtliche Möglichkeit, diese Unternehmen durch natürliche Schlüsselinformationen zu unterscheiden. Ein Ersatzschlüssel ist daher 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 H. P. Willmott und sie sind definitiv verschiedene Bücher, nicht nur verschiedene Ausgaben. In einem solchen Fall könnte ich auf das Aussehen der Bücher verweisen, oder auf das frühere oder spätere, aber es ist genauso gut, dass ich auf die ISBN zurückgreifen kann.

2
David Thornley

Pferd für Kurse. Um meine Voreingenommenheit auszudrücken; Ich bin in erster Linie ein 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 aufwenden, um sicherzustellen, dass sich Wertänderungen auswirken.

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

Die meisten traditionellen PL/SQL-Entwickler, mit denen ich gearbeitet habe, mochten keine Ersatzschlüssel, da die Anzahl der Tabellen pro Join sehr hoch war. Die zusätzlichen Joins hatten keinen Einfluss auf die Anwendungsleistung. Bei Datenbank-Dialekten, die Klauseln wie "X inner join Y on Xa = Yb" nicht unterstützen, oder Entwicklern, die diese Syntax nicht verwenden, erschweren die zusätzlichen Verknüpfungen für Ersatzschlüssel das Lesen der Abfragen und verlängern das Schreiben und Schreiben check: siehe @ Tony Andrews Beitrag. Wenn Sie jedoch ein ORM oder ein anderes SQL-Generierungsframework verwenden, werden Sie es nicht bemerken. Berührungsschreiben mildert auch.

1
WillC

Vielleicht nicht ganz relevant für dieses Thema, aber Kopfschmerzen, die ich mit Ersatzschlüsseln habe. Oracle Pre-Delivered Analytics erstellt automatisch generierte SKs für alle Dimensionstabellen im Warehouse und speichert diese auch für die 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, stimmen die SKs, die während der Aktualisierung zugewiesen wurden, nicht mehr mit den ursprünglichen Werten überein, die im Faktum gespeichert wurden ein vollständiges Neuladen aller Faktentabellen, die dazu gehören. Ich würde es vorziehen, dass selbst wenn die SK eine bedeutungslose Zahl wäre, es eine Möglichkeit geben würde, dass sie sich nicht für ursprüngliche/alte Datensätze ändern könnte. Wie viele wissen, dient Out-of-the-Box nur selten den Anforderungen eines Unternehmens, und wir müssen ständig Anpassungen vornehmen. Wir haben jetzt Daten im Wert von 3 Jahren in unserem Lager, und die vollständigen Neuladungen der Oracle Financial-Systeme sind 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.

1
lrb

Im Fall von Zeitpunktdatenbanken ist es am besten, eine Kombination aus Ersatz- und natürlichen Schlüsseln zu haben. z.B. Sie müssen die Informationen eines Mitglieds für einen Club nachverfolgen. Einige Attribute eines Mitglieds ändern sich nie. z. B. Geburtsdatum, aber Name kann sich ändern. Erstellen Sie also eine Mitgliedstabelle mit einem Ersatzschlüssel member_id und geben Sie eine Spalte für DOB ein. Erstellen Sie eine weitere Tabelle mit dem Namen person name und weisen Sie Spalten für member_id, member_fname, member_lname und date_updated auf. In dieser Tabelle wäre der natürliche Schlüssel member_id + date_updated.

0
kanad