Die beste Wahl für den Primärschlüssel der Tabelle Person

Question

Was ist Ihre Wahl für Primärschlüssel in Tabellen, die eine Person darstellen (wie Kunde, Benutzer, Kunde, Mitarbeiter usw.)? Meine erste Wahl wäre eine Sozialversicherungsnummer (SSN). Von der Verwendung der SSN wird jedoch aufgrund von Datenschutzbedenken und verschiedenen Vorschriften abgeraten. Die SSN kann sich im Laufe des Lebens einer Person ändern, was ein weiterer Grund dagegen ist.

Ich vermute, dass eine der Funktionen eines gut gewählten natürlichen Primärschlüssels darin besteht, Duplikate zu vermeiden. Ich möchte nicht, dass eine Person zweimal in der Datenbank registriert wird. Ein Surrogat oder ein generierter Primärschlüssel hilft nicht dabei, doppelte Einträge zu vermeiden. Wie kann ich dies am besten angehen?

Was ist der beste Weg, um Eindeutigkeit in Ihrer Anwendung für Person Entität zu garantieren und kann dies auf Datenbankebene mit Primärschlüssel oder Eindeutigkeitsbeschränkung behandelt werden?

Answer 1

Ich weiß nicht, welche Datenbank-Engine Sie verwenden, aber (zumindest bei MySQL - siehe 7.4.1. Machen Sie Ihre Daten so klein wie möglich ) Die Verwendung einer ganzen Zahl, die so kurz wie möglich ist, wird im Allgemeinen als die beste Lösung für Leistung und Speicherbedarf angesehen.

Ich würde eine ganze Zahl verwenden, auto_increment für diesen Primärschlüssel.
Die Idee dahinter:

• Wenn die PK kurz ist, hilft sie bei der Identifizierung jeder Zeile (es ist schneller und einfacher, zwei ganze Zahlen zu vergleichen als zwei lange Strings)
• Wenn eine in Fremdschlüsseln verwendete Spalte kurz ist, wird weniger Speicher für Fremdschlüssel benötigt, da der Wert dieser Spalte wahrscheinlich an mehreren Stellen gespeichert wird.

Und setzen Sie dann einen UNIQUE Index auf eine andere Spalte - diejenige, die die Eindeutigkeit bestimmt - wenn das möglich und/oder notwendig ist.

Edit: Hier sind ein paar andere Fragen/Antworten, die Sie interessieren könnten:

• Was ist die beste Praxis für Primärschlüssel in Tabellen?
• Wie gefallen Ihnen Ihre Primärschlüssel?
• Sollte ich ein eigenes Primärschlüsselfeld haben?
• Verwenden Sie artikelspezifische Präfixe und Autonummern für Primärschlüssel?

Answer 2

Wie oben erwähnt, verwenden Sie ein Auto-Inkrement als Primärschlüssel. Aber ich glaube nicht, dass dies Ihre eigentliche Frage ist.

Ihre eigentliche Frage ist, wie Sie doppelte Einträge vermeiden können. Theoretisch gibt es keine Möglichkeit - zwei Personen könnten am selben Tag geboren werden, denselben Namen tragen und im selben Haushalt leben, ohne dass für die eine oder die andere eine Sozialversicherungsnummer verfügbar wäre. (Eine könnte ein Ausländer sein, der das Land besucht).

Die Kombination aus vollständigem Namen, Geburtsdatum, Adresse und Telefonnummer ist jedoch in der Regel ausreichend, um Doppelungen zu vermeiden. Beachten Sie, dass Adressen unterschiedlich eingegeben werden können, dass Personen mehrere Telefonnummern haben können und dass Personen ihren zweiten Vornamen weglassen oder eine Initiale verwenden können. Es hängt davon ab, wie wichtig es ist, doppelte Einträge zu vermeiden, und wie groß Ihre Nutzerbasis ist (und damit die Wahrscheinlichkeit einer Kollision).

Wenn Sie die Sozialversicherungsnummer (SSN/SIN) herausfinden können, sollten Sie diese natürlich zur Bestimmung der Eindeutigkeit verwenden.

Answer 3

Welche Eigenschaften stehen Ihnen zur Verfügung? Welche davon sind für Ihre Anwendung wichtig? Zum Beispiel können keine zwei Menschen zur exakt gleichen Sekunde am exakt gleichen Ort geboren sein, aber Sie haben wahrscheinlich keinen Zugang zu diesen Daten mit dieser Genauigkeit! Sie müssen also anhand der Attribute, die Sie modellieren wollen, entscheiden, welche davon ausreichen, um ein akzeptables Maß an Datenintegrität zu gewährleisten. Wie auch immer Sie sich entscheiden, Sie haben Recht, wenn Sie sich auf die Aspekte der Datenintegrität (Verhinderung des Einfügens mehrerer Zeilen für dieselbe Person) Ihrer Auswahl konzentrieren.

Für Joins/Fremdschlüssel in anderen Tabellen ist es am besten, einen Surrogatschlüssel zu verwenden.

Ich bin zu der Überzeugung gelangt, dass die Verwendung des Wortes Primärschlüssel als eine falsche Bezeichnung oder bestenfalls als verwirrend. Jeder Schlüssel, egal ob Sie ihn als Primärschlüssel , Alternativer Schlüssel , Einzigartiger Schlüssel o Einzigartiger Index ist immer noch ein Schlüssel und erfordert, dass jede Zeile der Tabelle eindeutige Werte für die Attribute im Schlüssel enthält. In diesem Sinne sind alle Schlüssel gleichwertig. Vielmehr kommt es darauf an, ob es sich um natürliche Schlüssel (abhängig von sinnvollen Datenattributen des realen Domänenmodells) oder um Surrogate (unabhängig von realen Datenattributen) handelt.

Zweitens kommt es auch darauf an, wofür Sie den Schlüssel verwenden. Surrogatschlüssel sind eng und einfach und ändern sich nie (kein Grund dazu - sie bedeuten nichts). Daher sind sie eine bessere Wahl für Joins oder für Fremdschlüssel in anderen abhängigen Tabellen.

Aber um die Datenintegrität zu gewährleisten und das Einfügen mehrerer Zeilen für dieselbe Domäneneinheit zu verhindern, sind sie völlig nutzlos... Dafür brauchen Sie eine Art von Natürlicher Schlüssel die Sie aus den Ihnen zur Verfügung stehenden Daten ausgewählt haben und die Ihre Anwendung für einen bestimmten Zweck modelliert.

Der Schlüssel muss nicht zu 100 % unveränderlich sein. Wenn Sie (als Beispiel) Name, Telefonnummer und Geburtsdatum verwenden, können Sie, selbst wenn eine Person ihren Namen oder ihre Telefonnummer ändert, einfach den Wert in der Tabelle ändern. Solange keine andere Zeile bereits die neuen Werte in ihren Schlüsselattributen hat, ist alles in Ordnung.

Selbst wenn der von Ihnen gewählte Schlüssel nur in 99,9 % der Fälle funktioniert (z. B. wenn Sie das Pech haben, auf zwei Personen mit demselben Namen und derselben Telefonnummer zu treffen, die zufällig am selben Tag geboren wurden), sind zumindest 99,9 % Ihrer Daten garantiert korrekt und konsistent - und Sie können z. B. einfach die Zeit zu ihrem Geburtsdatum hinzufügen, um sie eindeutig zu machen, oder ein anderes Attribut zum Schlüssel hinzufügen, um sie zu unterscheiden. Solange Sie aufgrund der Änderung keine Datenwerte in Fremdschlüsseln in Ihrer gesamten Datenbank aktualisieren müssen (da Sie diesen Schlüssel nicht an anderer Stelle als FK verwenden), stehen Sie vor keinem größeren Problem.

Answer 4

Verwenden Sie einen automatisch generierten Integer-Primärschlüssel, und legen Sie dann eine eindeutige Einschränkung für alles fest, was Ihrer Meinung nach eindeutig sein sollte. Aber SSNs sind no Es wäre also keine gute Idee, eine Eindeutigkeitsbeschränkung für diese Spalte festzulegen, es sei denn, Sie halten es für ein gutes Geschäftsmodell, Kunden abzuweisen, weil Ihre Datenbank sie nicht akzeptiert.

Answer 5

Ich bevorzuge natürliche Schlüssel, aber eine Tabelle person ist ein verlorener Fall. SSNs sind nicht einzigartig und nicht jeder hat eine.