Surrogate vs. natürlicher / Geschäftsschlüssel [geschlossen]

https://stackoverflow.com/questions/63090

09-06-2019
|

Frage

Hier gehen wir wieder, immer noch das alte Argument entsteht ...

Würden wir besser, einen Geschäftsschlüssel als Primärschlüssel haben, oder würden wir lieber eine Surrogat-ID (das heißt eine SQL Server Identität) mit einer eindeutigen Einschränkung für das Business-Schlüsselfeld?

Bitte geben Sie Beispiele oder Beweis Ihre Theorie zu unterstützen.

Lösung

Beide. Haben Sie Ihren Kuchen und essen es.

Denken Sie daran, es ist nichts Besonderes an einem Primärschlüssel, mit der Ausnahme, dass sie als solche gekennzeichnet ist. Es ist nichts anderes als eine NOT NULL UNIQUE-Einschränkung, und eine Tabelle kann mehr als eine hat.

Wenn Sie einen Ersatzschlüssel verwenden, möchten Sie noch ein Geschäftsschlüssel Einzigartigkeit gemäß den Geschäftsregeln zu gewährleisten.

Andere Tipps

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

Stabilität : Ändern eines Schlüssels wegen eines Geschäfts oder natürliche Bedürfnis wird sich negativ auf verknüpfte Tabellen beeinflussen. Ersatzschlüssel nur selten, wenn überhaupt, muß geändert werden, weil es keine Bedeutung für den Wert gebunden ist.
Konvention . Hier können Sie eher eine standardisierte Primärschlüsselspalte Namenskonvention haben, als darüber nachzudenken, die, wie man mit verschiedenen Namen verbinden Tabellen für ihre PKs
Geschwindigkeit . Je nach PK-Wert und Typ, ein Ersatzschlüssel einer ganzen Zahl kann kleiner sein, schneller zu indizieren und sucht

Es scheint, dass niemand hat noch nichts gesagt zur Unterstützung nicht-Surrogat (Ich zögere zu sagen, „natürlich“) Tasten. So, hier geht ...

Nachteil von Ersatzschlüsseln ist, dass sie sinnlos (als Vorteil von einigen genannt, aber ...). Diese manchmal zwingt Sie viel mehr Tabellen in Ihre Abfrage zu verbinden, als wirklich nötig 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 ernsthaft glaubt, die folgende ist 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 der Code für myproject oder VALID oder HR Änderungen?“ Um die meine Antwort wäre: „Warum würden Sie Notwendigkeit , um es zu ändern?“ Diese sind nicht „natürlich“ Schlüssel in dem Sinne, dass einige außerhalb des Körpers, dass von nun an ‚gültig‘, Gesetze zu erlassen wird sollte als ‚gut‘ neu codiert werden. Nur ein kleiner Prozentsatz der „natürlichen“ Schlüssel fallen wirklich in diese Kategorie - SSN und Postleitzahl die üblichen Beispiele. Ich würde auf jeden Fall eine bedeutungslose Zifferntaste für Tabellen wie Person, Adresse verwenden -. Aber nicht für alles , die aus irgendeinem Grund die meisten Menschen hier scheinen zu befürworten

Siehe auch: meine Antwort auf eine andere Frage

Ersatzschlüssel (typischerweise ganzen Zahlen) hat den Mehrwert des Anbringens Ihre Tabelle, die Beziehungen schneller und wirtschaftlicher in der Lager- und Aktualisierungsgeschwindigkeit (noch besser, Fremdschlüssel müssen nicht aktualisiert werden, wenn Ersatzschlüssel verwendet wird, im Gegensatz zu Unternehmen Schlüsselfelder, die jetzt noch ändern und dann).

eine Primärschlüssel der Tabelle sollte zur Identifizierung eindeutig die Zeile, die hauptsächlich für Zwecke verwendet wird, verbinden. Denken Sie eine Tabelle Personen:. Namen können sich ändern, und sie sind nicht garantiert eindeutig

Think Unternehmen: Sie sind ein glückliches Merkin Unternehmen, das in Merkia mit anderen Unternehmen zu tun. Sie sind klug genug, nicht den Firmennamen als Primärschlüssel zu verwenden, so verwenden Sie Merkia einzigartige Identifizierungsnummer der Regierung in ihrer Gesamtheit von 10 alphanumerischen Zeichen. Dann ändert Merkia die Firma IDs, weil sie dachten, es wäre eine gute Idee sein. Es ist in Ordnung, verwenden Sie die DB-Engine kaskadiert Updates verfügen, für eine Änderung, die Sie nicht in erster Linie einbezogen werden sollte. Später, Ihr Unternehmen erweitert, und jetzt arbeiten Sie mit einem Unternehmen in Freedonia. Freedonian Unternehmen id sind bis zu 16 Zeichen. Sie müssen die Unternehmen ID Primärschlüssel (auch die Fremdschlüsselfelder in Bestellungen, Fragen, MoneyTransfers usw.), das Hinzufügen eines Land-Feldes in dem Primärschlüssel (auch in dem Fremdschlüssel) zu vergrößern. Autsch! Der Bürgerkrieg in Freedonia, wird es in drei Ländern aufgeteilt. Das Land Name Ihrer Mitarbeiter soll auf den neuen geändert werden; kaskadiert Updates zur Rettung. BTW, was ist Ihr Primärschlüssel? (Land, CompanyID) oder (CompanyID, Land)? Letzteres hilft schließt sich der ehemalige anderen Index vermeidet (oder vielleicht viele, sollten Sie Ihre Aufträge nach Ländern gruppiert wollen auch).

Alle diese sind kein Beweis, aber ein Hinweis darauf, dass ein Ersatzschlüssel eindeutig eine Zeile für alle Anwendungen zu identifizieren, Operationen einschließlich beitreten möchte, werden bevorzugt zu einer Business-Taste.

Surrogate Schlüssel wird nie einen Grund zu ändern. Ich kann nicht das gleiche über die natürlichen Schlüssel sagen. Nachnamen, E-Mails, ISBN nubmers -. Sie alle einen Tag ändern können

Ich hasse Ersatzschlüssel im Allgemeinen. Sie sollten nur verwendet werden, wenn es keine Qualität natürliche Schlüssel vorhanden ist. Es ist ziemlich absurd, wenn man darüber nachdenkt, zu denken, dass bedeutungslose Daten auf den Tisch Hinzufügen könnten die Dinge besser machen.

Hier sind meine Gründe:

Wenn natürlichen Schlüssel verwenden, Tabellen sind in der Art und Weise gruppiert, dass sie am häufigsten somit gesuchten Abfragen schneller zu machen.
Wenn Ersatzschlüssel verwenden, müssen Sie eindeutigen Indizes auf logische Schlüsselspalten hinzufügen. Sie müssen noch logische doppelte Daten zu verhindern. Zum Beispiel können Sie nicht zulassen, dass zwei Organisationen mit dem gleichen Namen in Ihrer Organisation Tisch, obwohl das Stück eine Surrogat id-Spalte ist.
Wenn Ersatzschlüssel als Primärschlüssel verwendet werden, es ist viel weniger klar, was die natürlichen Primärschlüssel sind. Bei der Entwicklung Sie wissen wollen, was der Spalten setzen die Tabelle eindeutig zu machen.
In einer zu vielen Beziehung Ketten, die logischen Schlüsselketten. So zum Beispiel, haben Organisationen viele Konten und Konten haben viele Rechnungen. So ist der logische-Schlüssel der Organisation ist OrgName. Der logische-Schlüssel des Accounts ist OrgName, AccountID. Der logische-Schlüssel der Rechnung ist OrgName, AccountID, InvoiceNumber.

Als Ersatzschlüssel verwendet wird, werden die Schlüsselketten abgeschnitten, indem nur einen Fremdschlüssel zum nächstgelegenen Eltern haben. Zum Beispiel hat die Rechnungstabelle keine OrgName Spalte haben. Es hat nur eine Spalte für die AccountID. Wenn Sie Rechnungen für eine bestimmte Organisation suchen möchten, dann müssen Sie die Organisation, Konto und Rechnungs Tabellen verknüpfen. Wenn Sie die logischen Schlüssel verwenden, dann könnten Sie die Organisation Tabellenabfrage direkt.
Ersatzschlüssel Werte von Lookup-Tabellen speichern verursacht Tabellen mit sinnlose Zahlen gefüllt werden. Um die Daten, komplexe Ansichten anzeigen müssen erstellt werden, um alle der Lookup-Tabellen verbinden. Eine Nachschlagetabelle ist gemeint, einen Satz von akzeptablen Werten für eine Spalte zu halten. Es sollte nicht durch Speichern eines ganzzahligen Ersatzschlüssel statt zu kodifizieren. Es gibt nichts in den Normalisierungsregeln, die vorschlagen, dass Sie eine Leihmutter ganze Zahl anstelle des Wertes speichern sollen selbst.
Ich habe drei verschiedene Datenbank-Bücher. Nicht einer von ihnen zeigt Ersatzschlüssel verwendet wird.

Ich möchte meine Erfahrung mit Ihnen auf diesem endlosen Krieg teilen: D auf natürliche vs Ersatzschlüssel Dilemma. Ich denke, dass beide Ersatzschlüssel (künstliche automatisch generiert ist) und natürlichen Schlüssel (bestehend aus Spalte (n) mit Domain Bedeutung) haben Vor und cons . Also je nach Ihrer Situation, könnte es mehr relevant sein, ein Verfahren oder das andere zu wählen.

Wie es scheint, dass viele Menschen anwesend Ersatzschlüssel als fast perfekte Lösung und natürlichen Schlüssel wie die Pest, ich auf der anderen Sicht Argumente konzentrieren:

Nachteile von Ersatzschlüsseln

Surrogate Tasten sind:

Quelle von Performance-Problemen:
- Sie werden in der Regel unter Verwendung von automatisch inkrementierte Spalten implementiert, die bedeuten:
  - Ein Round-Trip in die Datenbank jedes Mal, wenn Sie eine neue ID zu bekommen (ich weiß, dass dieses Caching verbessert werden kann oder [f] hilo gleichermaßen Algorithmen, aber immer noch diese Methoden haben ihre eigenen Nachteile).
  - Wenn eintägige Sie Ihre Daten von einem Schema in ein anderes verschieben müssen (Es kommt ganz regelmäßig in meiner Firma mindestens) dann könnten Sie Id Kollisionsprobleme auftreten. Und Ja, ich weiß, dass Sie UUIDs verwenden können, aber diejenigen, dauert erfordert 32 hexadezimalen Ziffern! (Wenn Sie die Datenbankgröße sorgen dann kann es ein Problem sein).
  - Wenn Sie eine Sequenz für alle Ersatzschlüssel verwenden, dann - sicher -. Sie werden mit Konkurrenzsituationen auf Ihrer Datenbank am Ende
Fehler anfällig. Eine Sequenz hat eine max_value Grenze so - als Entwickler - müssen Sie die Aufmerksamkeit auf folgende Punkte gelegt:
- Sie müssen Zyklus Sequenz (wenn der max-Wert, den es erreicht zu 1,2 zurückgeht, ...).
- Wenn Sie die Sequenz als Ordnungs (über die Zeit) werden mit Ihren Daten müssen Sie den Fall des Radfahrens handhaben (siehe Spalte mit der Id 1 könnte neuer sein als max-Wert mit dem Id-Reihe - 1).
- Stellen Sie sicher, dass Ihr Code (und sogar Ihre Client-Schnittstellen, die nicht, wie es eine interne Id soll geschehen sollte sein) unterstützt 32b / 64b ganzen Zahlen, die Sie Ihre Sequenzwerte speichern verwendet.
Sie haben nicht nicht dupliziert Daten garantieren. Sie können immer zwei Zeilen mit den gleichen Spaltenwerte haben, aber mit einem anderen generierten Wert. Für mich ist die DAS Problem des Ersatzschlüssels aus einer Datenbank-Design Sicht.
Mehr in Wikipedia ...

Mythen auf natürliche Schlüssel

Composite-Tasten sind weniger ineffizienter als Ersatzschlüssel. Nein! Es hängt von dem verwendeten Datenbank-Engine:
- Oracle
- MySQL
Natürlicher Schlüssel existiert nicht im wirklichen Leben. Sorry, aber es gibt sie! In der Luftfahrt-Industrie, zum Beispiel, wird die folgende Tupel immer eindeutig sein in Bezug auf eine bestimmte geplant Flug (Fluggesellschaft, departureDate, Flugnummer, operationalSuffix). Allgemeiner gesagt, wenn eine Reihe von Business-Daten garantiert eindeutig von einem bestimmten Standard sein, dann ist dieser Satz von Daten ein [gut] natürlichen Schlüssel Kandidaten.
Natürliche Tasten „verschmutzen das Schema“ der Kinder Tabellen. Für mich ist das mehr ein Gefühl als ein echtes Problem. je könnte effizienter sein als eine einzelne Spalte von 11 Bytes einen 4 Spalten Primärschlüssel von 2 Bytes. Außerdem können die vier Säulen verwendet werden, um die untergeordnete Tabelle direkt abfragen (durch die 4 Spalten in einer where-Klausel verwendet wird) ohne Tabelle an der Mutter zu verbinden.

Fazit

natürlichen Schlüssel verwenden, wenn es relevant ist, dies zu tun und Ersatzschlüssel zu verwenden, wenn es besser ist, sie zu nutzen.

Hoffe, dass dies jemand geholfen!

Alway einen Schlüssel verwenden, die keine betriebswirtschaftliche Bedeutung hat. Es ist nur gute Praxis.

EDIT: Ich habe versucht, einen Link, um es online zu finden, aber ich konnte es nicht. Doch in 'Patterns of Enterprise Archtecture' [Fowler] es hat eine gute Erklärung, warum sollten Sie nicht verwenden etwas anderes als ein Schlüssel ohne andere Bedeutung als ein Schlüssel zu sein. Es läuft darauf hinaus, die Tatsache, dass es nur einen Job und einen Job hat.

Surrogate Tasten sind sehr praktisch, wenn Sie planen, ein ORM-Tool verwenden, um Ihre Datenklassen zu behandeln / generieren. Während Sie zusammengesetzte Schlüssel mit einigen der fortgeschritteneren Mapper (sprich: Hibernate) verwenden können, fügt es einige Komplexität zu Ihrem Code.

(Natürlich Datenbank Puristen argumentieren, dass auch der Begriff eines Ersatzschlüssels ist ein Greuel.)

Ich bin ein Fan von uids für Ersatzschlüssel, wenn geeignete Verwendung. Der Hauptgewinn mit sich ist, dass Sie den Schlüssel im Voraus z.B. können Sie eine Instanz einer Klasse mit der ID bereits festgelegt und garantiert eindeutig sein, während mit, sagen wir, eine ganze Zahl Schlüssel erstellen Sie auf 0 oder -1 und Aktualisierung auf einen geeigneten Wert auf Standard müssen, wenn Sie / Update einzuspielen.

UIDs haben Sanktionen in Bezug auf die Suche und Geschwindigkeit zu verbinden, obwohl so hängt es von der Anwendung in Frage, ob sie sind wünschenswert.

einen Ersatzschlüssel zu verwenden ist meiner Meinung nach besser, da es keine Chance es zu verändern. Fast alles, was ich davon denken, Sie können als natürliche Schlüssel verwenden, könnte sich ändern könnte (Disclaimer: nicht immer wahr, aber häufig).

Ein Beispiel könnte eine DB von Autos sein - auf dem ersten Blick könnte man denken, dass das Kennzeichen als Schlüssel verwendet werden könnte. Aber diese geändert werden könnte, so würde das eine schlechte Idee sein. Sie würden nicht wirklich wollen, dass, um herauszufinden, nach die App die Freigabe, wenn jemand kommt zu Ihnen wissen wollen, warum sie nicht ihre Nummernschild, um ihre glänzenden neuen personalisierten eine ändern.

Verwenden Sie immer eine einzelne Spalte, Ersatzschlüssel, wenn überhaupt möglich. Dies macht verbindet sowie Einsätze / updates / löscht viel sauberer, weil Sie nur verantwortlich sind für ein einzelnes Stück Tracking-Informationen, den Datensatz zu erhalten.

Dann, je nach Bedarf, stapeln Ihre Geschäftsschlüssel als einzigartiges contraints oder Indizes. So bleiben Sie Datenintegrität intakt.

Die Geschäftslogik / natürliche Schlüssel kann sich ändern, aber die phisical Schlüssel einer Tabelle sollte sich nie ändern.

Auf einem Data-Warehouse-Szenario Ich glaube, besser ist, den Ersatzschlüssel Pfad zu folgen. Zwei Gründe:

Sie sind unabhängig von dem Quellsystem und Änderungen dort als Datentyp --such change-- werden Sie nicht beeinflussen.
Ihre DW benötigen weniger physischen Raum, da Sie nur Integer-Datentypen für Ihren Ersatzschlüssel verwenden. Auch Ihre Indizes wird besser funktionieren.

Ersatzschlüssel kann nützlich sein, wenn Geschäftsinformationen oder identisch sein ändern. Firmennamen müssen nicht nach dem ganzen Land, eindeutig sein. Angenommen, Sie mit zwei Unternehmen beschäftigen namens Smith Electronics, ein in Kansas und einem in Michigan. Sie können sie nach Adressen unterscheiden, aber das wird sich ändern. Auch kann der Zustand ändern; was ist, wenn Smith Electronics von Kansas City, Kansas nach Kansas City, Missouri über den Fluss bewegt? Es gibt keine offensichtliche Möglichkeit, diese Unternehmen verschiedene mit natürlichen Schlüsselinformationen zu halten, so dass ein Ersatzschlüssel ist sehr nützlich.

Denken Sie an den Ersatzschlüssel wie eine ISBN-Nummer. Normalerweise Sie ein Buch von Titel und Autor identifizieren. Allerdings habe ich zwei Bücher bekam den Titel „Pearl Harbor“ von H. P. Willmott, und sie sind auf jeden Fall verschiedene Bücher, nicht nur verschiedene Ausgaben. In einem solchen Fall, dass konnte ich auf die Blicke der Bücher beziehen, oder die früher im Vergleich zu den späteren, aber es ist genauso gut habe ich die ISBN zurückgreifen.

Zur Erinnerung: es keine gute Praxis ist zu platzieren gruppierten Indizes auf Zufallsersatzschlüssel heißt GUIDs, die XY8D7-DFD8S lesen, da sie SQL Server keine Fähigkeit hat, physisch Art diese Daten. Sie sollten stattdessen eindeutige Indizes auf diesen Daten platzieren, wenn es auch einfach von Vorteil sein kann, um SQL Profiler für die Haupttabellenoperationen ausführen und dann diese Daten in die Database Engine Tuning Advisor platzieren.

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

Fall 1: Ihr Tisch ist eine Lookup-Tabelle mit weniger als 50 Typen (Einsätzen)

Mit Business / natürliche Schlüssel . Zum Beispiel:

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: Ihr Tisch ist eine Tabelle mit Tausenden von Einsätzen

Mit Surrogat / autoincrement Tasten . Zum Beispiel:

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 Tabelle PEOPLE auswählen, ohne Verwendung von mit Tabelle JOB beitreten, aber nur mit: "SELECT * FROM PEOPLE WHERE JOBCODE = 'PRG'"

Im zweiten Fall:

Ihre Datenbankabfragen sind schneller, weil Ihr Primärschlüssel ist eine ganze Zahl
Sie brauchen nicht, sich die Mühe mit den nächsten eindeutigen Schlüssel zu finden, weil die Datenbank selbst der nächste autoincrement gibt.

Dies ist einer der Fälle, wo ein Ersatzschlüssel ziemlich immer Sinn macht. Es gibt Fälle, in denen Sie entweder entscheiden, was für die Datenbank am besten sind, oder, was das Beste für Ihr Objekt-Modell, aber in beiden Fällen mit einem bedeutungslosen Schlüssel oder GUID ist eine bessere Idee. Es macht Indizierung einfacher und schneller, und es ist eine Identität für Ihr Objekt, das sich nicht verändert.

Pferd für die Kurse. Zu sagen, meine Vorurteile; Ich bin ein Entwickler zuerst, also bin ich hauptsächlich mit der Benutzer eine funktionierende Anwendung zu geben.

Ich habe auf Systemen mit natürlichen Schlüsseln gearbeitet, und hatte viel Zeit dafür, dass zu verbringen, dass Wertänderungen würden Welligkeit durch.

Ich habe auf Systeme mit nur Ersatzschlüsseln gearbeitet, und der einzige Nachteil ein Mangel an denormalised Daten für die Partitionierung wurde.

Die meisten traditionellen PL / SQL-Entwickler ich gearbeitet habe nicht wie Ersatzschlüssel wegen der Anzahl der Tabellen pro beitreten, aber unsere Test- und Produktionsdatenbanken erhöhten nie ins Schwitzen; die zusätzliche schließt sich nicht die Anwendungsleistung nicht beeinträchtigte. Mit Datenbank-Dialekten, die Klauseln nicht unterstützen wie „X Exklusionsverknüpfung Y auf Xa = Yb“ oder Entwickler, die nicht über diese Syntax verwenden, tritt das extra für Ersatzschlüssel haben die Abfragen schwerer lesen machen, und mehr zu geben und überprüfen: siehe @Tony Andrews Post. Aber wenn Sie ein ORM oder andere SQL-Generation Framework verwenden, werden Sie es nicht bemerken. Touch-Eingabe mildert auch.

Vielleicht zu diesem Thema nicht ganz relevant, sondern Kopfschmerzen ich mit Ersatzschlüssel haben zu tun. Oracle Pre-gelieferten Analysen erstellt automatisch generierte SKs auf alle seine Maßtabellen im Lager, und er speichert auch die auf den Tatsachen. Also, wann immer sie (Dimensionen) müssen neu geladen werden als neue Spalten hinzugefügt oder müssen für alle Elemente in der Dimension aufgefüllt werden, die während der Aktualisierung zugewiesen SKs macht die SKs nicht synchron mit den ursprünglichen Werten der Tatsache gespeichert, zwingen ein komplettes Neuladen aller Faktentabellen, die ihm beitreten. Ich würde es vorziehen, dass selbst wenn die SK eine bedeutungslose Zahl ist, gäbe es eine Möglichkeit, dass es nicht für Original / alte Datensätze ändern könnte. Wie viele wissen, dient out-of-the-Box selten ein Bedürfnisse der Organisation, und wir haben ständig anpassen. Wir haben jetzt 3yrs im Wert von Daten in unserem Lager und vollständigen Nachladen von den Oracle-Finanzsystemen sind sehr groß. Also in meinem Fall, werden sie nicht von der Dateneingabe erzeugt, sondern in einem Lager aufgenommen Berichterstattung Leistung zu helfen. Ich bekomme es, aber unsere ändern sich, und es ist ein Alptraum.

Im Fall der Zeitpunkt Datenbank ist es am besten Kombination von Surrogat und natürliche Schlüssel. z.B. Sie müssen für einen Club-Nutzer Informationen verfolgen. Einige Attribute eines Mitglieds ändern sich nie. z Geburtsdatum, aber Namen kann sich ändern. So erstellen Sie eine Tabelle mit einem Mitglied member_id Ersatzschlüssel und eine Spalte für DOB. Erstellen Sie eine andere Tabelle Rufene Namen und haben Spalten für member_id, member_fname, member_lname, date_updated. In dieser Tabelle würde der natürliche Schlüssel member_id + date_updated.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow