Sollte jede Tabelle einen Primärschlüssel haben?

339

Ich erstelle eine Datenbanktabelle und habe keinen logischen Primärschlüssel zugewiesen. Also denke ich darüber nach, es ohne Primärschlüssel zu lassen, aber ich fühle mich ein bisschen schuldig. Sollte ich?

Sollte jede Tabelle einen Primärschlüssel haben?

database  database-design 
— Daniel Silveira
quelle
5
Könnten Sie etwas mehr Details über die Tabelle geben? Die Antwort ist wahrscheinlich "Ja".
— Ryan Bair
7
Ja, jede Tabelle sollte einen Primärschlüssel haben.
— Syed Tayyab Ali

Antworten:

312

Kurze Antwort: ja .

Lange Antwort:

  • Sie müssen Ihren Tisch auf etwas verbinden können
  • Wenn Sie möchten, dass Ihre Tabelle geclustert wird, benötigen Sie eine Art Primärschlüssel.
  • Wenn Ihr Tischdesign keinen Primärschlüssel benötigt, überdenken Sie Ihr Design: Höchstwahrscheinlich fehlt Ihnen etwas. Warum identische Aufzeichnungen führen?

In MySQL erstellt die InnoDB-Speicher-Engine immer einen Primärschlüssel, wenn Sie ihn nicht explizit angegeben haben, sodass eine zusätzliche Spalte erstellt wird, auf die Sie keinen Zugriff haben.

Beachten Sie, dass ein Primärschlüssel zusammengesetzt sein kann.

Wenn Sie eine Viele-zu-Viele-Verknüpfungstabelle haben, erstellen Sie den Primärschlüssel für alle an der Verknüpfung beteiligten Felder. So stellen Sie sicher, dass Sie nicht zwei oder mehr Datensätze haben, die einen Link beschreiben.

Neben den logischen Konsistenzproblemen profitieren die meisten RDBMS-Engines davon, diese Felder in einen eindeutigen Index aufzunehmen.

Und da für jeden Primärschlüssel ein eindeutiger Index erstellt werden muss, sollten Sie ihn deklarieren und sowohl logische Konsistenz als auch Leistung erzielen.

In diesem Artikel in meinem Blog erfahren Sie, warum Sie immer einen eindeutigen Index für eindeutige Daten erstellen sollten:

PS Es gibt einige sehr, sehr spezielle Fälle, in denen Sie keinen Primärschlüssel benötigen.

Meistens enthalten sie Protokolltabellen, die aus Leistungsgründen keine Indizes haben .

— Quassnoi
quelle
Sie haben immer noch einen Primärschlüssel, den zusammengesetzten
— Kristof
2
@annakata: Sie sollten einen zusammengesetzten Primärschlüssel haben
— Quassnoi
1
"Und da jeder PRIMARY KEY das Erstellen eines EINZIGARTIGEN Index beinhaltet", gilt dies nicht für Oracle. Man kann einen nicht eindeutigen Index verwenden, um einen Primärschlüssel zu erzwingen. Tatsächlich ist es manchmal ERFORDERLICH, dass eindeutige und PK-Einschränkungen nicht eindeutige Indizes verwenden.
— Stephanie Seite
3
Nur ein Kommentar zur rhetorischen Frage "Warum identische Aufzeichnungen führen?". Beachten Sie, dass nur das Hinzufügen einer PK nicht sicherstellt, dass keine Duplizierung vorliegt. Oft ist die PK für den Benutzer nicht sichtbar. Daher sind die sichtbaren Felder wichtig, die doppelte Daten enthalten können. Abhängig von Ihrem Design kann dies wünschenswert sein oder nicht.
— Rossco
1
Schlüssel haben nichts mit Verbindbarkeit zu tun. Das Clustering-Argument hängt davon ab, welches DBMS Sie verwenden, und mischt logische und physikalische Überlegungen.
— Jon Heggland
35

Immer am besten einen Primärschlüssel haben. Auf diese Weise entspricht es der ersten Normalform und ermöglicht es Ihnen, den Pfad der Datenbanknormalisierung fortzusetzen .

Wie von anderen angegeben, gibt es einige Gründe, keinen Primärschlüssel zu haben, aber die meisten werden nicht beschädigt, wenn es einen Primärschlüssel gibt

— Michael Wheeler
quelle
5
@PaulSuart Daten müssen nicht immer in ihrer normalen Form vorliegen. Wenn Daten sehr groß werden, sollten sie nicht in ihrer normalen Form gehalten werden, da sonst der Zugriff auf Daten für Abfragen, die Tabellenverknüpfungen usw. durchführen, fürchterlich langsam ist. Normale Formen sind eine "Idealisierung" und praktisch nur möglich, wenn nicht erwartet wird, dass Daten wachsen enorm.
— Pacerier
13

So ziemlich jedes Mal, wenn ich eine Tabelle ohne Primärschlüssel erstellt habe und dachte, ich würde keinen brauchen, bin ich zurückgegangen und habe einen hinzugefügt. Ich erstelle jetzt sogar meine Join-Tabellen mit einem automatisch generierten Identitätsfeld, das ich als Primärschlüssel verwende.

— Tvanfosson
quelle
12
Eine Join-Tabelle ist ein Primärschlüssel - ein zusammengesetzter Schlüssel, der aus den PKs beider Datensätze besteht, die verbunden werden. ZB TABELLE ERSTELLEN PersonOrder (PersonId int, OrderId int, PRIMARY KEY (PersonId, OrderId)).
— Keith Williams
3
Ja, aber was ist, wenn die Verknüpfungstabelle auch ein drittes Attribut hat, sagen wir "OrderDate". Würden Sie das auch dem zusammengesetzten Schlüssel hinzufügen? IMHO nein - weil es weiter reduzierbar ist und nicht dem nicht reduzierbaren Charakter dient, den ein Primärschlüssel haben sollte.
— Stevek
13

Mit Ausnahme einiger sehr seltener Fälle (möglicherweise einer Viele-zu-Viele-Beziehungstabelle oder einer Tabelle, die Sie vorübergehend zum Massenladen großer Datenmengen verwenden) würde ich dem Sprichwort folgen:

Wenn es keinen Primärschlüssel hat, ist es keine Tabelle!

Marc

— marc_s
quelle
9
Genau genommen ist dieser Satz falsch. Tabellen können "Tabellen anzeigen" sein, die von Ihrer Abfragesprache erstellt wurden. Ein RDBMS besteht aus Beziehungen, nicht aus Tabellen. Dieser Satz sollte lauten: "Wenn es keinen Primärschlüssel hat, ist es keine Beziehung!".
— Stevek
Oder vielleicht: "Wenn es keine Kandidatenschlüssel gibt, handelt es sich nicht um eine relationale Tabelle." Aber sehen Sie sich die sehr seltenen Fälle an, in denen es in Ordnung ist, eine Tabelle zu haben, die keine Beziehung darstellt.
— Walter Mitty
Warum hätte eine Viele-zu-Viele-Tabelle keinen Primärschlüssel? Sie können einen separaten Primärschlüssel erstellen und dann einen eindeutigen Index für den Ersatz von Fremdschlüsseln erstellen. Ich denke, es ist besser, an jedem Tisch einen Primärschlüssel zu haben. Selbst in einer Massenladetabelle möchten Sie möglicherweise einen Primärschlüssel separat identifizieren, der die importierten Daten nicht enthält, da dies Ihnen helfen kann, doppelte Datensätze in einem ETL-Prozess zu identifizieren. Es scheint mir, dass jede Tabelle immer noch einen Primärschlüssel haben sollte, auch wenn es etwas mehr Speicherplatz ist. Eine von einer Ansicht erstellte Tabelle ist eine Teilmenge einer Tabelle und keine Tabelle selbst.
— John Ernest
1
In einer Beziehungstabelle mit vielen zu vielen können Sie einen zusammengesetzten Primärschlüssel erstellen, der aus beiden IDs für die Beziehungen besteht.
— Jaap
8

Müssen Sie diese Tabelle jemals mit anderen Tabellen verbinden? Benötigen Sie eine Möglichkeit, einen Datensatz eindeutig zu identifizieren? Wenn die Antwort Ja lautet, benötigen Sie einen Primärschlüssel. Angenommen, 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-Mails, Telefonnummern usw. benötigen, um festzustellen, ob sich diese Sally Smith von der Sally Smith unterscheidet, und Sie diese Informationen in verwandten Tabellen speichern, da die Person mehrere Telefone und Adressen haben kann Angenommen, Sally Smith heiratet John Jones und wird Sally Jones. Wenn Sie keinen künstlichen Schlüssel auf dem Tisch haben, haben Sie beim Aktualisieren des Namens nur 7 Sally Smiths in Sally Jones geändert, obwohl nur einer von ihnen geheiratet und ihren Namen geändert hat.

Sie sagen, Sie haben keinen natürlichen Schlüssel, daher haben Sie auch keine Feldkombinationen, die Sie eindeutig machen könnten. Dies macht den künstlichen Schlüssel kritisch.

Ich habe immer dann festgestellt, dass ein künstlicher Schlüssel ein absolutes Muss für die Aufrechterhaltung der Datenintegrität ist, wenn ich keinen natürlichen Schlüssel habe. Wenn Sie einen natürlichen Schlüssel haben, können Sie diesen stattdessen als Schlüsselfeld verwenden. Aber ich persönlich bevorzuge 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 ist ein Feld. Sie werden es später bereuen, wenn Sie keine eingeben.

— HLGEM
quelle
7

Fügen Sie es einfach hinzu, es wird Ihnen später leid tun, wenn Sie es nicht getan haben (Auswählen, Löschen, Verknüpfen usw.)

— raphaëλ
quelle
6

Es ist eine gute Praxis, an jedem Tisch eine PK zu haben, aber es ist kein MUSS. Höchstwahrscheinlich benötigen Sie einen eindeutigen Index und / oder einen Clustered-Index (PK oder nicht), je nach Bedarf.

Lesen Sie die Abschnitte Primärschlüssel und Clustered-Indizes in Books Online (für SQL Server).

" PRIMARY KEY-Einschränkungen identifizieren die Spalte oder den Satz von Spalten mit Werten, 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 in einem Primärschlüssel NULL eingeben. Wir empfehlen die Verwendung einer kleinen ganzzahligen Spalte als Primärschlüssel. Jede Tabelle sollte einen Primärschlüssel haben. Eine Spalte oder Kombination von Spalten, die als Primärschlüsselwert gelten, wird als Kandidatenschlüssel bezeichnet. "

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

— endo64
quelle
1
— endo64
4
Diese Seite ist ziemlich dumm. Erstens wird aus Leistungsgründen ein Primärschlüssel benötigt. Durch das Lesen seiner Seite erfahre ich, dass das Hinzufügen einer ID zu einer Buchtabelle nutzlos ist, da der Text des Buches eindeutig ist. Offensichtlich hat der Typ nie mit Datenbanken gearbeitet. Aber er hat auch Probleme zu verstehen, was er kritisiert. Seite geschrieben, dass 1) ein PK-Wert auf eine Zeile verweist 2) Sie können 2 Tabellen durch einen beliebigen Satz von Spalten verbinden. Es gibt keinen Widerspruch. Es ist erstaunlich, dass ein Autor eines wissenschaftlichen Artikels die Grundlagen der relationalen Theorie nicht versteht.
— Federico Razzoli
1
"Erstens wird aus Leistungsgründen ein Primärschlüssel benötigt." Dies ist falsch. PK hat keinen direkten Einfluss auf die Leistung. Das Fehlen einer PK kann zu vielen Problemen führen (Identifizieren einer Zeile, Verbinden usw.), aber die Leistung gehört nicht dazu. Wenn Sie eine PK in einer Tabelle erstellen, erstellt SQL Server einen eindeutigen Clustered-Index. Dieser Index wirkt sich auf die Leistung aus, nicht auf die PK selbst. Als reales Beispiel hat meine Tabelle einen Clustered Index für die Datumsspalte und eine PK für ein GUID-Feld, da meine Zeilen physisch über die Datumsspalte in der Tabelle geordnet werden sollten, da alle Abfragen einen Datumsbereich haben (in meinem Fall).
— Endo64
Dieser Clustered-Index ist eine Variante des Primärschlüssels, der von SQL Server und mehreren anderen DBMS erstellt wurde. Sind Sie sicher, dass es eine gute Idee ist, es zu verwenden? In MySQL ist dies beispielsweise nicht aus mehreren undokumentierten Gründen der Fall.
— Federico Razzoli
1
Beachten Sie, dass GUID in InnoDB kein optimaler Typ für PKs ist. Alle Indizes enthalten einen Verweis auf die PK. Je größer die PK ist, desto größer sind alle anderen Indizes.
— Federico Razzoli
6

Stimmen Sie der vorgeschlagenen Antwort nicht zu. Die kurze Antwort lautet: NEIN .

Der Primärschlüssel dient dazu, eine Zeile in der Tabelle eindeutig zu identifizieren, um eine Beziehung zu einer anderen Tabelle herzustellen. Traditionell wird zu diesem Zweck ein automatisch inkrementierter ganzzahliger Wert verwendet, aber es gibt Variationen davon.

Es gibt jedoch Fälle, in denen beispielsweise Zeitreihendaten protokolliert werden, in denen das Vorhandensein eines solchen Schlüssels einfach nicht benötigt wird und nur Speicherplatz beansprucht. Eine Zeile einzigartig zu machen ist einfach ... nicht erforderlich!

Ein kleines Beispiel: Tabelle A: LogData

Columns:  DateAndTime, UserId, AttribA, AttribB, AttribC etc...

Kein Primärschlüssel erforderlich.

Tabelle B: Benutzer

Columns: Id, FirstName, LastName etc.

Primärschlüssel (ID) erforderlich, um als "Fremdschlüssel" für die LogData-Tabelle verwendet zu werden.

— Theodore Zographos
quelle
3

Ich weiß, dass Sie zur Verwendung bestimmter Funktionen der Rasteransicht in .NET einen Primärschlüssel benötigen, damit die Rasteransicht weiß, welche Zeile aktualisiert / gelöscht werden muss. Die allgemeine Praxis sollte darin bestehen, einen Primärschlüssel oder einen Primärschlüsselcluster zu haben. Ich persönlich bevorzuge das erstere.

— Tacoman667
quelle
3

Um es zukunftssicher zu machen, sollten Sie es wirklich tun. Wenn Sie es replizieren möchten, benötigen Sie eine. Wenn Sie es an einen anderen Tisch bringen möchten, wird Ihr Leben (und das der armen Narren, die es nächstes Jahr pflegen müssen) so viel einfacher.

— StewNoble
quelle
Ich bin noch nicht davon überzeugt, dass es notwendig ist, aber "mach es, weil sonst jemand später mit den Konsequenzen fertig werden muss" reicht aus, um mich auf die Seite zu stellen. Ich kann die Spalte später immer einfach fallen lassen, wenn es sich lohnt, sie zu verkleinern ...
— ArtOfWarfare
2

Ich habe immer einen Primärschlüssel, auch wenn ich am Anfang noch keinen Zweck dafür habe. Es gab einige Male, in denen ich irgendwann eine PK in einer Tabelle brauchte, die keine hat, und es ist immer schwieriger, sie später einzufügen. Ich denke, es ist eher ein Vorteil, immer einen einzubeziehen.

— rvarcher
quelle
2

Ich bin in der Rolle der Pflege der vom Offshore-Entwicklungsteam erstellten Anwendung. Jetzt habe ich alle möglichen Probleme in der Anwendung, da das ursprüngliche Datenbankschema in einigen Tabellen keine PRIMARY KEYS enthielt. Lassen Sie also bitte andere Menschen nicht unter Ihrem schlechten Design leiden. Es ist immer eine gute Idee, Primärschlüssel in Tabellen zu haben.

— Shiva
quelle
1

Kurz gesagt, nein. Sie müssen jedoch berücksichtigen, dass bestimmte Clientzugriffs-CRUD-Vorgänge dies erfordern. Für die Zukunftssicherung verwende ich immer Primärschlüssel.

— Rich.Carpenter
quelle
1

Wenn Sie den Ruhezustand verwenden, ist es nicht möglich, eine Entität ohne Primärschlüssel zu erstellen. Dieses Problem kann zu Problemen führen, wenn Sie mit einer vorhandenen Datenbank arbeiten, die mit einfachen SQL / DDL-Skripten erstellt wurde und kein Primärschlüssel hinzugefügt wurde

— Schildmeijer
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.