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.

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.

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.

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

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.

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.

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.

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:
   • Orakel
   • MySQL
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!

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.