it-swarm.com.de

Was ist die beste Vorgehensweise für Primärschlüssel in Tabellen?

Beim Entwerfen von Tabellen habe ich mir angewöhnt, eine einzige Spalte zu haben und den Primärschlüssel zu erstellen. Dies wird je nach Anforderung auf drei Arten erreicht:

  1. Identity Integer-Spalte, die automatisch inkrementiert wird.
  2. Eindeutiger Bezeichner (GUID)
  3. Eine Spalte mit einem kurzen Zeichen (x) oder einer Ganzzahl (oder einem anderen relativ kleinen numerischen Typ), die als Zeilenbezeichnerspalte dienen kann

Nummer 3 wird für relativ kleine Suchvorgänge verwendet, bei denen es sich meistens um gelesene Tabellen handelt, die einen eindeutigen Zeichenfolgencode mit statischer Länge oder einen numerischen Wert wie eine Jahreszahl oder eine andere Zahl aufweisen.

In den meisten Fällen verfügen alle anderen Tabellen entweder über eine automatisch inkrementierende Ganzzahl oder einen eindeutigen Bezeichner-Primärschlüssel.

Die Frage :-)

Ich habe vor kurzem angefangen, mit Datenbanken zu arbeiten, die keine konsistente Zeilenidentifikation haben und Primärschlüssel werden zurzeit über verschiedene Spalten gruppiert. Einige Beispiele:

  • datumZeit/Zeichen
  • datumZeit/Ganzzahl
  • datetime/varchar
  • char/nvarchar/nvarchar

Gibt es dafür einen gültigen Fall? Ich hätte für diese Fälle immer eine Identitäts- oder eine eindeutige Identifizierungsspalte definiert.

Darüber hinaus gibt es viele Tabellen ohne Primärschlüssel. Was sind die gültigen Gründe dafür, wenn überhaupt?

Ich versuche zu verstehen, warum Tische so entworfen wurden, wie sie waren, und es scheint mir ein großes Durcheinander zu sein, aber vielleicht gab es gute Gründe dafür.

Eine dritte Frage hilft mir beim Entschlüsseln der Antworten: Gibt es in Fällen, in denen der zusammengesetzte Primärschlüssel aus mehreren Spalten besteht, einen besonderen Vorteil dieser Methode gegenüber einem Ersatz-/künstlichen Schlüssel? Ich denke hauptsächlich an Leistung, Wartung, Administration usw.?

240
Lloyd Cotten

Ich folge ein paar Regeln:

  1. Primärschlüssel sollten so klein wie nötig sein. Bevorzugen Sie einen numerischen Typ, da numerische Typen in einem viel kompakteren Format als Zeichenformate gespeichert sind. Dies liegt daran, dass die meisten Primärschlüssel Fremdschlüssel in einer anderen Tabelle sind und auch in mehreren Indizes verwendet werden. Je kleiner Ihr Schlüssel, desto kleiner der Index, desto weniger Seiten im Cache werden Sie verwenden.
  2. Primärschlüssel sollten sich niemals ändern. Das Aktualisieren eines Primärschlüssels sollte immer ausgeschlossen sein. Dies liegt daran, dass es höchstwahrscheinlich in mehreren Indizes und als Fremdschlüssel verwendet wird. Das Aktualisieren eines einzelnen Primärschlüssels kann zu einer Welligkeit der Änderungen führen.
  3. Verwenden Sie NICHT "Ihr Problemprimärschlüssel" als Ihren Logikmodellprimärschlüssel. Zum Beispiel Passnummer, Sozialversicherungsnummer oder Angestelltenvertragsnummer, da sich diese "Primärschlüssel" für reale Situationen ändern können.

In Bezug auf Surrogate vs Natural Key beziehe ich mich auf die obigen Regeln. Wenn der natürliche Schlüssel klein ist und sich niemals ändert, kann er als Primärschlüssel verwendet werden. Wenn der natürliche Schlüssel groß ist oder sich wahrscheinlich ändert, verwende ich Ersatzschlüssel. Wenn es keinen Primärschlüssel gibt, erstelle ich immer noch einen Ersatzschlüssel, da Sie erfahrungsgemäß immer Tabellen zu Ihrem Schema hinzufügen und wünschen, Sie würden einen Primärschlüssel einrichten.

232
Logicalmind

Natürliche Verse künstliche Schlüssel sind eine Art religiöse Debatte in der Datenbank-Community - siehe dieser Artikel und andere, mit denen sie verknüpft sind. Ich bin weder dafür, dass immer künstliche Schlüssel hat, noch dafür, dass niemals mit ihnen. Ich würde von Fall zu Fall entscheiden, zum Beispiel:

  • US-Bundesstaaten: Ich würde eher state_code ('TX' für Texas usw.) als state_id = 1 für Texas wählen
  • Mitarbeiter: Normalerweise würde ich eine künstliche employee_id erstellen, da es schwierig ist, etwas anderes zu finden, das funktioniert. SSN oder ein gleichwertiger Dienst kann funktionieren, es kann jedoch Probleme geben, z. B. wenn ein neuer Tischler seine SSN noch nicht angegeben hat.
  • Gehaltsverlauf für Mitarbeiter: (employee_id, start_date). Ich würde keine künstliche employee_salary_history_id erstellen . Welchem ​​Punkt würde es dienen (außer "dumme Konsistenz" )

Überall dort, wo künstliche Schlüssel verwendet werden, sollten Sie auch eindeutige Einschränkungen für die natürlichen Schlüssel festlegen. Verwenden Sie zum Beispiel state_id, wenn Sie müssen, aber dann deklarieren Sie besser eine eindeutige Einschränkung für state_code. Andernfalls erhalten Sie mit Sicherheit:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas
87
Tony Andrews

Nur ein zusätzlicher Kommentar zu etwas, das oft übersehen wird. Manchmal hat die Nichtverwendung eines Ersatzschlüssels Vorteile für die untergeordneten Tabellen. Nehmen wir an, wir haben ein Design, mit dem Sie mehrere Unternehmen in einer Datenbank betreiben können (möglicherweise handelt es sich um eine gehostete Lösung oder was auch immer).

Nehmen wir an, wir haben diese Tabellen und Spalten:

Company:
  CompanyId   (primary key)

CostCenter:
  CompanyId   (primary key, foreign key to Company)
  CostCentre  (primary key)

CostElement
  CompanyId   (primary key, foreign key to Company)
  CostElement (primary key)

Invoice:
  InvoiceId    (primary key)
  CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)
  CostCentre   (in foreign key to CostCentre)
  CostElement  (in foreign key to CostElement)

Falls das letzte Bit keinen Sinn ergibt, Invoice.CompanyId ist Teil zweier Fremdschlüssel, einer für die Tabelle CostCentre und einer für die Tabelle CostElement. Der Primärschlüssel ist (InvoiceId, CompanyId).

In diesem Modell ist es nicht möglich, ein CostElement von einer Firma und ein CostCentre von einer anderen Firma zu vermasseln und zu referenzieren. Wenn ein Ersatzschlüssel für die Tabellen CostElement und CostCentre verwendet würde, wäre dies der Fall.

Je weniger Chancen zu vermasseln, desto besser.

25
WW.

Ich vermeide die Verwendung natürlicher Schlüssel aus einem einfachen Grund - menschliches Versagen. Obwohl häufig natürliche eindeutige Kennungen verfügbar sind (SSN, VIN, Kontonummer usw.), müssen diese von einem Menschen korrekt eingegeben werden. Wenn Sie SSNs als Primärschlüssel verwenden, jemand während der Dateneingabe einige Zahlen transponiert und der Fehler nicht sofort entdeckt wird, müssen Sie Ihren Primärschlüssel ändern.

Meine Primärschlüssel werden alle vom Datenbankprogramm im Hintergrund verwaltet und der Benutzer merkt nichts davon.

21
Paul

Es ist kein Problem, Ihren Primärschlüssel aus verschiedenen Feldern zu erstellen, das ist ein natürlicher Schlüssel .

Sie können eine Identitätsspalte (die einem eindeutigen Index für die Kandidatenfelder zugeordnet ist) verwenden, um einen Ersatzschlüssel zu erstellen.

Das ist eine alte Diskussion. In den meisten Situationen bevorzuge ich Ersatzschlüssel.

Aber es gibt keine Entschuldigung für das Fehlen eines Schlüssels.

RE: EDIT

Ja, darüber gibt es viele Kontroversen: D

Ich sehe keinen offensichtlichen Vorteil bei natürlichen Schlüsseln, abgesehen von der Tatsache, dass sie die natürliche Wahl sind. Sie werden immer in Name, SocialNumber - oder so ähnlich denken - anstelle von idPerson .

Ersatzschlüssel sind die Antwort auf einige der Probleme, die natürliche Schlüssel haben (z. B. die Weitergabe von Änderungen).

Wenn Sie sich an Leihmutterschaften gewöhnen, wirkt es sauberer und handlicher.

Aber am Ende werden Sie feststellen, dass es nur um den Geschmack oder die Einstellung geht. Menschen "denken besser" mit natürlichen Schlüsseln, andere nicht.

13

Tabellen sollten immer einen Primärschlüssel haben. Wenn dies nicht der Fall ist, sollten es AutoIncrement-Felder sein.

Manchmal wird der Primärschlüssel weggelassen, weil viele Daten übertragen werden und dies den Prozess verlangsamen kann (abhängig von der Datenbank). ABER es sollte danach hinzugefügt werden.

Ein Kommentar zur Verknüpfungstabelle, das ist richtig, es ist eine Ausnahme, ABER Felder sollten FK sein, um die Integrität zu erhalten, und in einigen Fällen können diese Felder auch Primärschlüssel sein, wenn das Duplizieren in Verknüpfungen nicht zulässig ist. Um jedoch eine einfache Form beizubehalten, da Ausnahmen bei der Programmierung häufig vorkommen, sollte ein Primärschlüssel vorhanden sein, um die Integrität Ihrer Daten zu gewährleisten.

11

Neben all diesen guten Antworten möchte ich nur einen guten Artikel veröffentlichen, den ich gerade gelesen habe: Die große Primärschlüsseldebatte.

Um nur ein paar Punkte zu nennen:

Der Entwickler muss bei der Auswahl eines Primärschlüssels für jede Tabelle einige Regeln anwenden:

  • Der Primärschlüssel muss jeden Datensatz eindeutig identifizieren.
  • Der Primärschlüsselwert eines Datensatzes darf nicht null sein.
  • Der Primärschlüsselwert muss beim Erstellen des Datensatzes vorhanden sein.
  • Der Primärschlüssel muss stabil bleiben. Sie können die Primärschlüsselfelder nicht ändern.
  • Der Primärschlüssel muss kompakt sein und möglichst wenige Attribute enthalten.
  • Der Primärschlüsselwert kann nicht geändert werden.

Natürliche Schlüssel (neigen dazu), die Regeln zu brechen. Ersatzschlüssel entsprechen den Regeln. (Lesen Sie diesen Artikel besser durch, es ist Ihre Zeit wert!)

8
RayLuo

Was ist das Besondere am Primärschlüssel?

Was ist der Zweck einer Tabelle in einem Schema? Was ist der Zweck eines Schlüssels einer Tabelle? Was ist das Besondere am Primärschlüssel? Die Diskussionen um Primärschlüssel scheinen den Punkt zu übersehen, dass der Primärschlüssel Teil einer Tabelle und diese Tabelle Teil eines Schemas ist. Was für die Tabelle und die Tabellenbeziehungen am besten ist, sollte den verwendeten Schlüssel steuern.

Tabellen (und Tabellenbeziehungen) enthalten Fakten zu Informationen, die Sie aufzeichnen möchten. Diese Fakten sollten in sich geschlossen, aussagekräftig, leicht verständlich und widerspruchsfrei sein. Aus Entwurfssicht sollten sich andere Tabellen, die einem Schema hinzugefügt oder daraus entfernt wurden, nicht auf die betreffende Tabelle auswirken. Es muss einen Zweck geben, die Daten zu speichern, die sich nur auf die Informationen selbst beziehen. Um zu verstehen, was in einer Tabelle gespeichert ist, muss kein wissenschaftliches Forschungsprojekt durchgeführt werden. Kein für denselben Zweck gespeicherter Fakt sollte mehrmals gespeichert werden. Schlüssel sind eine Gesamtheit oder ein Teil der aufgezeichneten Informationen, die eindeutig sind, und der Primärschlüssel ist der speziell festgelegte Schlüssel, der der primäre Zugriffspunkt auf die Tabelle sein soll (dh er sollte aus Gründen der Datenkonsistenz und -nutzung ausgewählt und nicht nur eingefügt werden Performance).

  • ASIDE: Die meisten Datenbanken, die von Anwendungsprogrammierern entworfen und entwickelt werden (was ich manchmal bin), haben leider den Nebeneffekt, dass das Beste für die Anwendung oder das Anwendungsframework häufig die Primärschlüsselauswahl für Tabellen bestimmt. Dies führt zu Ganzzahlen und GUID Schlüssel (da diese für Anwendungsframeworks einfach zu verwenden sind) und zu monolithischen Tabellenentwürfen (da diese die Anzahl von Anwendungsframeworkobjekten reduzieren, die zur Darstellung der Daten im Speicher erforderlich sind). Diese Entscheidungen zum anwendungsgesteuerten Datenbankdesign führen bei skalierter Verwendung zu erheblichen Datenkonsistenzproblemen. Auf diese Weise entworfene Anwendungs-Frameworks führen auf natürliche Weise zu Tabellen-zu-Zeit-Designs. „Teilaufzeichnungen“ werden in Tabellen erstellt und die Daten werden im Laufe der Zeit ausgefüllt Interaktion wird vermieden, oder wenn sie verwendet wird, führt sie zu inkonsistenten Daten, wenn die Anwendung nicht ordnungsgemäß funktioniert. Diese Entwürfe führen zu Daten, die bedeutungslos (oder schwer zu verstehen) sind. und duplizierte Daten.

Es wurde gesagt, dass Primärschlüssel so klein wie nötig sein sollten. Ich würde sagen, dass Schlüssel nur so groß wie nötig sein sollten. Das zufällige Hinzufügen sinnloser Felder zu einer Tabelle sollte vermieden werden. Es ist sogar noch schlimmer, einen Schlüssel aus einem zufällig hinzugefügten, bedeutungslosen Feld zu machen, insbesondere wenn dadurch die Verknüpfungsabhängigkeit von einer anderen Tabelle zum Nicht-Primärschlüssel aufgehoben wird. Dies ist nur dann sinnvoll, wenn die Tabelle keine geeigneten Kandidatenschlüssel enthält. Dieses Vorkommen ist jedoch sicherlich ein Zeichen für einen schlechten Schemaentwurf, wenn es für alle Tabellen verwendet wird.

Es wurde auch gesagt, dass sich Primärschlüssel niemals ändern sollten, da die Aktualisierung eines Primärschlüssels immer ausgeschlossen sein sollte. Das Aktualisieren ist jedoch dasselbe wie Löschen, gefolgt von Einfügen. Nach dieser Logik sollten Sie niemals einen Datensatz mit einem Schlüssel aus einer Tabelle löschen und dann einen weiteren Datensatz mit einem zweiten Schlüssel hinzufügen. Das Hinzufügen des Ersatzprimärschlüssels entfernt nicht die Tatsache, dass der andere Schlüssel in der Tabelle vorhanden ist. Das Aktualisieren eines Nicht-Primärschlüssels einer Tabelle kann die Bedeutung der Daten zerstören, wenn andere Tabellen über einen Ersatzschlüssel von dieser Bedeutung abhängig sind (z. B. eine Statustabelle mit einem Ersatzschlüssel, dessen Statusbeschreibung von "Verarbeitet" in "Abgebrochen" geändert wurde 'würde definitiv die Daten verfälschen). Was immer ausgeschlossen sein sollte, ist die Zerstörung der Datenbedeutung.

Trotzdem bin ich dankbar für die vielen schlecht gestalteten Datenbanken, die heutzutage in Unternehmen existieren (bedeutungslose, durch Ersatzschlüssel verschlüsselte, beschädigte 1NF-Ungetüme), denn das bedeutet, dass Menschen, die sich mit dem richtigen Datenbankdesign auskennen, eine endlose Menge an Arbeit leisten müssen . Traurigerweise fühle ich mich manchmal wie Sisyphus, aber ich wette, er hatte (vor dem Absturz) einen verdammt guten 401k. Halten Sie sich bei wichtigen Fragen zum Datenbankdesign von Blogs und Websites fern. Wenn Sie Datenbanken entwerfen, schlagen Sie CJ Date nach. Sie können auch auf Celko für SQL Server verweisen, aber nur, wenn Sie zuerst Ihre Nase halten. Auf der Oracle-Seite verweisen wir auf Tom Kyte.

7
Luke

Ein natürlicher Schlüssel, falls verfügbar, ist normalerweise am besten. Wenn also datetime/char eindeutig die Zeile identifiziert und beide Teile für die Zeile von Bedeutung sind, ist das großartig.

Wenn nur die Datums- und Uhrzeitangabe von Bedeutung ist und der Buchstabe nur angeheftet wird, um ihn eindeutig zu machen, können Sie auch ein Identifizierungsfeld verwenden.

6
James Curran

Für mich ist es wichtig, wie viel von der Geschäftslogik Sie in Ihrer Datenbank haben möchten, ob es sich um natürliche oder künstliche Schlüssel handelt. Sozialversicherungsnummer (SSN) ist ein gutes Beispiel.

"Jeder Client in meiner Datenbank wird und muss eine SSN haben." Bam, fertig, mach es zum Primärschlüssel und sei fertig damit. Denken Sie daran, wenn sich Ihre Geschäftsregel ändert, werden Sie verbrannt.

Ich mag selbst keine natürlichen Schlüssel, da ich Erfahrung mit sich ändernden Geschäftsregeln habe. Wenn Sie jedoch sicher sind, dass sich dies nicht ändert, werden möglicherweise einige kritische Verknüpfungen verhindert.

5
Dan Williams

Ich vermute, Steven A. Lowes aufgerollte Zeitungstherapie ist für den Designer der ursprünglichen Datenstruktur erforderlich.

Abgesehen davon kann GUIDs als Primärschlüssel ein Leistungsfresser sein. Ich würde es nicht empfehlen.

4
Andrew Rollings

Ich suche nach natürlichen Primärschlüsseln und benutze sie, wo ich kann.

Wenn keine natürlichen Schlüssel gefunden werden können, ziehe ich ein GUID einem INT ++ vor, da SQL Server Bäume verwendet, und es ist schlecht, immer Schlüssel an das Ende in Bäumen anzufügen.

Bei Tabellen, bei denen es sich um viele-zu-viele-Kopplungen handelt, verwende ich einen zusammengesetzten Primärschlüssel der Fremdschlüssel.

Da ich das Glück habe, SQL Server zu verwenden, kann ich Ausführungspläne und Statistiken mit dem Profiler und dem Abfrageanalysator untersuchen und herausfinden, wie einfach die Leistung meiner Schlüssel ist.

3
Guge

Sie sollten einen zusammengesetzten oder zusammengesetzten Primärschlüssel verwenden, der aus mehreren Feldern besteht.

Dies ist eine völlig akzeptable Lösung, gehen Sie hier für weitere Informationen :)

3
adam

Auch ich benutze immer eine numerische ID-Spalte. In Oracle verwende ich die Zahl (18,0) ohne wirklichen Grund über der Zahl (12,0) (oder was auch immer ein Int und nicht ein Long ist). Vielleicht möchte ich mich nie darum kümmern, ein paar Milliarden Zeilen rein zu bekommen die db!

Ich füge auch eine erstellte und geänderte Spalte (Typ Timestamp) für das grundlegende Tracking hinzu, wo es sinnvoll erscheint.

Es macht mir nichts aus, eindeutige Einschränkungen für andere Spaltenkombinationen festzulegen, aber ich mag meine ID, die erstellten und geänderten Basisanforderungen wirklich.

3
JeeBee

Hier sind meine eigenen Faustregeln, auf die ich mich nach mehr als 25 Jahren Entwicklungserfahrung festgelegt habe.

  • Alle Tabellen sollten einen einspaltigen Primärschlüssel haben, der automatisch inkrementiert wird.
  • Schließen Sie es in jede Ansicht ein, die aktualisierbar sein soll
  • Der Primärschlüssel sollte im Kontext Ihrer Anwendung keine Bedeutung haben. Dies bedeutet, dass es sich nicht um eine SKU oder eine Kontonummer oder eine Mitarbeiter-ID oder um andere Informationen handeln sollte, die für Ihre Anwendung von Bedeutung sind. Es ist lediglich ein eindeutiger Schlüssel, der einer Entität zugeordnet ist.

Der Primärschlüssel wird von der Datenbank zu Optimierungszwecken verwendet und sollte von Ihrer Anwendung nur zur Identifizierung einer bestimmten Entität oder in Bezug auf eine bestimmte Entität verwendet werden.

Wenn Sie immer einen Primärschlüssel mit einem einzigen Wert haben, ist die Durchführung von UPSERTs sehr einfach.

Verwenden Sie zusätzliche Indizes, um mehrspaltige Schlüssel zu unterstützen, die in Ihrer Anwendung eine Bedeutung haben.

3

Ich benutze immer eine Autonummer oder ein Identitätsfeld.

Ich arbeitete für einen Client, der SSN als Primärschlüssel verwendet hatte, und musste dann aufgrund der HIPAA-Vorschriften auf eine "MemberID" wechseln. Dies verursachte eine Menge Probleme beim Aktualisieren der Fremdschlüssel in verwandten Tabellen. Das Festhalten an einem einheitlichen Standard einer Identitätsspalte hat mir geholfen, ein ähnliches Problem in allen meinen Projekten zu vermeiden.

2
Matt

GUIDs kann als Primärschlüssel verwendet werden, Sie müssen jedoch den richtigen Typ GUID) erstellen, damit die Leistung gut ist.

Sie müssen COMB-GUIDs generieren. Ein guter Artikel dazu und zur Leistungsstatistik ist Die Kosten für GUIDs als Primärschlüssel.

Auch Code zum Erstellen von COMB-GUIDs in SQL ist in niqueidentifier vs identity (- Archiv ) .

1
Donny V.

Alle Tabellen sollten haben einen Primärschlüssel. Andernfalls handelt es sich um einen HEAP - dies kann in bestimmten Situationen gewünscht sein (hohe Einfügungslast, wenn die Daten dann beispielsweise über einen Service Broker in eine andere Datenbank oder Tabelle repliziert werden).

Für Nachschlagetabellen mit einem geringen Zeilenvolumen können Sie einen 3-CHAR-Code als Primärschlüssel verwenden, da dieser weniger Platz beansprucht als ein INT, der Leistungsunterschied jedoch vernachlässigbar ist. Ansonsten würde ich immer eine INT verwenden, es sei denn, Sie haben eine Referenztabelle, die möglicherweise einen zusammengesetzten Primärschlüssel enthält, der aus Fremdschlüsseln aus zugeordneten Tabellen besteht.

1
Coolcoder

Wenn Sie wirklich das ganze Hin und Her dieser uralten Debatte durchlesen möchten, suchen Sie bei Stack Overflow nach "natural key". Sie sollten Seiten mit Ergebnissen zurückerhalten.

1
Tom H

Ich werde meine Vorliebe für natürliche Schlüssel offen legen - verwenden Sie sie, wo immer dies möglich ist, da sie Ihnen das Leben in der Datenbankverwaltung erheblich erleichtern. Ich habe in unserer Firma einen Standard festgelegt, dass alle Tabellen die folgenden Spalten haben:

  • Zeilen ID (GUID)
  • Ersteller (Zeichenfolge; hat standardmäßig den Namen des aktuellen Benutzers (SUSER_SNAME() in T-SQL))
  • Erstellt (DateTime)
  • Zeitstempel

Die Zeilen-ID enthält einen eindeutigen Schlüssel für jede Tabelle und wird in jedem Fall automatisch für jede Zeile generiert (und Berechtigungen verhindern, dass Personen sie bearbeiten). Es wird in angemessener Weise garantiert, dass sie für alle Tabellen und Datenbanken eindeutig ist. Wenn ein ORM-System einen einzelnen ID-Schlüssel benötigt, muss dieser verwendet werden.

In der Zwischenzeit ist die tatsächliche PK nach Möglichkeit ein natürlicher Schlüssel. Meine internen Regeln lauten wie folgt:

  • Personen - Verwenden Sie einen Ersatzschlüssel, z. INT. Wenn es sich um einen internen Benutzer handelt, ist der Active Directory-Benutzer GUID eine akzeptable Wahl
  • Nachschlagetabellen (z. B. StatusCodes) - Verwenden Sie einen kurzen CHAR-Code. Es ist leichter zu merken als INTs, und in vielen Fällen werden die Papierformulare und Benutzer es auch der Kürze halber verwenden (z. B. Status = "E" für "Abgelaufen", "A" für "Genehmigt", "NADIS" für "Kein Asbest festgestellt" In Sample ")
  • Verknüpfungstabellen - Kombination von FKs (z. B. EventId, AttendeeId)

Im Idealfall erhalten Sie eine natürliche, für Menschen lesbare und einprägsame PK und eine ORM-freundliche GUID mit einer ID pro Tabelle.

Vorsichtsmaßnahme: Die von mir verwalteten Datenbanken enthalten eher 100.000 Datensätze als Millionen oder Milliarden. Wenn Sie also Erfahrung mit größeren Systemen haben, die meinem Rat widersprechen, können Sie mich gerne ignorieren!

0
Keith Williams

Wir machen viele Joins und zusammengesetzte Primärschlüssel sind gerade zu einem Leistungsfresser geworden. Ein einfaches int oder long behebt viele Probleme, obwohl Sie einen zweiten Kandidatenschlüssel einführen. Es ist jedoch viel einfacher und verständlicher, in einem Feld gegenüber drei Feldern beizutreten.

0
Dan Blair