Sollte jede einzelne Tabelle einen Primärschlüssel haben?

Question

Ich erstelle eine Datenbanktabelle und habe ihr keinen logischen Primärschlüssel zugewiesen. Sollte jede einzelne Tabelle einen Primärschlüssel haben?

Answer 1

Fügen Sie es einfach hinzu, Sie werden es später bereuen, wenn Sie es nicht getan haben (auswählen, löschen, verlinken usw.)

Answer 2

Werden Sie diese Tabelle jemals mit anderen Tabellen verbinden müssen? Benötigen Sie eine Möglichkeit zur eindeutigen Identifizierung eines Datensatzes? Wenn ja, brauchen Sie einen Primärschlüssel. Nehmen wir an, Ihre Daten sind so etwas wie eine Kundentabelle, die die Namen der Personen enthält, die Kunden sind. Möglicherweise gibt es keinen natürlichen Schlüssel, da Sie die Adressen, E-Mail-Adressen, Telefonnummern usw. benötigen, um festzustellen, ob sich diese Sally Smith von jener Sally Smith unterscheidet, und Sie werden diese Informationen in Bezugstabellen speichern, da die Person mehrere Telefone, Adressen, E-Mail-Adressen usw. haben kann. Angenommen, Sally Smith heiratet John Jones und wird zu Sally Jones. Wenn Sie keinen künstlichen Schlüssel in der Tabelle haben, haben Sie bei der Aktualisierung des Namens gerade 7 Sally Smiths in Sally Jones geändert, obwohl nur eine von ihnen geheiratet und ihren Namen geändert hat. Und woher wissen Sie in diesem Fall ohne einen künstlichen Schlüssel, welche Sally Smith in Chicago und welche in LA wohnt?

Sie sagen, Sie haben keinen natürlichen Schlüssel, also haben Sie auch keine Kombinationen von Feldern, die Sie eindeutig machen können, was den künstlichen Schlüssel kritisch macht.

Ich habe festgestellt, dass immer dann, wenn ich keinen natürlichen Schlüssel habe, ein künstlicher Schlüssel ein absolutes Muss für die Wahrung der Datenintegrität ist. Wenn Sie einen natürlichen Schlüssel haben, können Sie diesen stattdessen als Schlüsselfeld verwenden. Ich persönlich bevorzuge aber immer noch einen künstlichen Schlüssel und einen eindeutigen Index für den natürlichen Schlüssel, es sei denn, der natürliche Schlüssel besteht aus einem einzigen Feld. Sie werden es später bereuen, wenn Sie keinen solchen Schlüssel einfügen.

Answer 3

Es ist eine gute Praxis, für jede Tabelle einen PK zu haben, aber es ist kein MUSS. Höchstwahrscheinlich benötigen Sie einen eindeutigen Index und/oder einen Cluster-Index (mit oder ohne PK), je nach Bedarf.

Lesen Sie die Abschnitte Primärschlüssel und geclusterte Indizes auf Books Online (für SQL Server)

" PRIMARY KEY-Beschränkungen identifizieren die Spalte oder den Satz von Spalten, die Werte haben, die eine Zeile in einer Tabelle eindeutig identifizieren. Keine zwei Zeilen in einer Tabelle können denselben Primärschlüsselwert haben. Sie können für keine Spalte eines Primärschlüssels NULL eingeben. Wir empfehlen, eine kleine, ganzzahlige Spalte als Primärschlüssel zu verwenden. Jede Tabelle sollte einen Primärschlüssel haben. Eine Spalte oder eine Kombination von Spalten, die als Primärschlüsselwert in Frage kommt, wird als Kandidatenschlüssel bezeichnet. "

Aber sehen Sie sich auch dies an: http://www.aisintl.com/case/primary_and_foreign_key.html

Answer 4

Ich bin spät dran, aber ich wollte meine Meinung dazu sagen:

Sollte jede einzelne Tabelle einen Primärschlüssel haben?

• Wenn Sie von "Relational Albegra" sprechen, lautet die Antwort Ja . Die Modellierung von Daten auf diese Weise erfordert, dass die Entitäten und Tabellen einen Primärschlüssel haben. Das Problem mit der relationalen Algebra (abgesehen von der Tatsache, dass es etwa 20 verschiedene, nicht zusammenpassende Varianten davon gibt) ist, dass sie nur auf dem Papier existiert. Mit relationaler Algebra kann man keine Anwendungen in der realen Welt erstellen.

• Wenn Sie nun über Datenbanken aus der realen Welt sprechen, halten sie sich teilweise/meist an die relationale Algebra, indem sie das Beste davon nehmen und andere Teile davon übersehen. Außerdem bieten Datenbank-Engines heutzutage umfangreiche nicht-relationale Funktionen (wir schreiben jetzt das Jahr 2020). In diesem Fall lautet die Antwort also Nein . Auf jeden Fall haben 99,9 % meiner Tabellen in der realen Welt einen Primärschlüssel, aber es gibt begründete Ausnahmen. Ein Beispiel dafür sind Ereignis-/Protokolltabellen (mehrere Indizes, aber kein einziger Schlüssel in Sicht).

Unterm Strich ist es in transaktionalen Anwendungen, die dem Entity/Relationship-Modell folgen, sehr sinnvoll, Primärschlüssel für fast (wenn nicht sogar alle) Tabellen zu haben. Wenn Sie sich jemals entscheiden, den Primärschlüssel einer Tabelle wegzulassen, stellen Sie sicher, dass Sie einen guten Grund dafür haben und darauf vorbereitet sind, Ihre Entscheidung zu verteidigen.

Answer 5

Um sie zukunftssicher zu machen, sollten Sie das wirklich tun. Wenn Sie sie nachbauen wollen, brauchen Sie eine. Wenn Sie ihn mit einem anderen Tisch verbinden wollen, wird Ihr Leben (und das der armen Trottel, die ihn nächstes Jahr warten müssen) so viel einfacher sein.