it-swarm.com.de

Sollte jede Tabelle einen Primärschlüssel haben?

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?

311
Daniel Silveira

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: Wahrscheinlich fehlt Ihnen etwas. Warum identische Aufzeichnungen führen?

In MySQL erstellt die InnoDB-Speicher-Engine immer einen Primärschlüssel, wenn Sie diesen 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 bei jedem Primärschlüssel ein eindeutiger Index erstellt werden muss, sollten Sie diesen 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:

P.S Es gibt einige sehr, sehr Sonderfälle, in denen Sie keinen Primärschlüssel benötigen.

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

290
Quassnoi

Immer am besten einen Primärschlüssel haben. Auf diese Weise erfüllt es erste normale Form und ermöglicht es Ihnen, auf dem Pfad Datenbanknormalisierung fortzufahren.

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

31
Michael Wheeler

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 sagen:

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

Marc

12
marc_s

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

12
tvanfosson

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.).

7
raphaëλ

Müssen Sie diese Tabelle jemals mit anderen Tabellen verknüpfen? 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 Kunden enthält. Möglicherweise gibt es keinen natürlichen Schlüssel, da Sie die Adressen, E-Mails, Telefonnummern usw. benötigen, um festzustellen, ob sich dieser Sally Smith von diesem 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 zu Sally Jones. Wenn Sie keinen künstlichen Schlüssel auf dem Tisch haben, haben Sie beim Aktualisieren des Namens 7 Sally Smiths in Sally Jones geändert, obwohl nur einer von ihnen geheiratet und ihren Namen geändert hat. Und natürlich in diesem Fall ohne künstlichen Schlüssel, woher weißt du, welche Sally Smith in Chicago lebt und welche in LA?

Sie sagen, Sie haben keinen natürlichen Schlüssel, daher haben Sie auch keine eindeutigen Feldkombinationen. Dies macht den künstlichen Schlüssel kritisch.

Ich habe 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 persönlich bevor der natürliche Schlüssel ein Feld ist, bevorzuge ich immer noch einen künstlichen Schlüssel und einen eindeutigen Index für den natürlichen Schlüssel. Sie werden es später bereuen, wenn Sie keine eingeben.

7
HLGEM

Es ist eine gute Praxis, einen PK auf jedem Tisch 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 Ihren Anforderungen.

Lesen Sie die Abschnitte zu Primärschlüsseln und Clustered-Indizes in der Onlinedokumentation (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 nicht NULL eingeben Für jede Spalte in einem Primärschlüssel wird die Verwendung einer kleinen Ganzzahlspalte als Primärschlüssel empfohlen. Jede Tabelle sollte einen Primärschlüssel haben. Eine Spalte oder Kombination von Spalten, die als Primärschlüsselwert qualifiziert sind, wird als Kandidatenschlüssel bezeichnet.

Schauen Sie sich das aber auch an: http://www.aisintl.com/case/primary_and_foreign_key.html

6
endo64

Ich weiß, dass Sie zum Verwenden bestimmter Funktionen der Rasteransicht in .NET einen Primärschlüssel benötigen, damit die Rasteransicht weiß, welche Zeile aktualisiert/gelöscht werden muss. In der Regel sollte ein Primärschlüssel oder ein Primärschlüsselcluster vorhanden sein. Ich persönlich bevorzuge das erstere.

3
Tacoman667

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

3
StewNoble

Ich habe immer einen Primärschlüssel, auch wenn ich anfangs noch keinen Grund 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 gibt mehr Vorteile, immer einen einzubeziehen.

2
rvarcher

Wenn Sie den Ruhezustand verwenden, können Sie keine Entität ohne Primärschlüssel 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

1
Schildmeijer

Ich bin in der Rolle der Verwaltung von Anwendungen, die vom Offshore-Entwicklungsteam erstellt wurden. Jetzt habe ich alle möglichen Probleme in der Anwendung, da das ursprüngliche Datenbankschema in einigen Tabellen keine PRIMARY KEYS enthielt. Bitte lassen Sie andere Menschen nicht unter Ihrem schlechten Design leiden. Es ist immer eine gute Idee, Primärschlüssel auf Tabellen zu haben.

1
Shiva

Stimme der vorgeschlagenen Antwort nicht zu. Die kurze Antwort lautet: NO .

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, der jedoch variiert.

Es gibt jedoch Fälle, in denen das Vorhandensein eines solchen Schlüssels einfach nicht erforderlich ist und nur Speicherplatz beansprucht, beispielsweise das Aufzeichnen von Zeitreihendaten. 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.

1

Kurz gesagt, nein. Beachten Sie jedoch, dass dies für bestimmte CRUD-Vorgänge mit Clientzugriff erforderlich ist. Für zukünftige Überprüfungen verwende ich in der Regel immer Primärschlüssel.

1
Rich.Carpenter