Die Wahl von guten Primärschlüsseln, Kandidatenschlüsseln und Fremdschlüsseln, die sie verwenden, ist eine äußerst wichtige Aufgabe für das Datenbankdesign - so viel Kunst wie Wissenschaft. Die Designaufgabe hat sehr spezifische Designkriterien.
Was sind die Kriterien?
Die Kriterien für die Berücksichtigung eines Primärschlüssels sind:
Der Primärschlüssel ist etwas, das eine Zeile / einen Datensatz eindeutig identifiziert. Es kann sich auch um mehrere Spalten handeln, was als Composite bezeichnet wird.
Da der Primärschlüssel oft für Auslandsreferenzen verwendet wird, sollte er so stabil wie möglich sein. Alle Daten in der Datenbank sind veränderbar, vorausgesetzt, dass sich jemand mit einem Konto mit den entsprechenden Berechtigungen verbindet. Aus diesem Grund bieten Datenbanken die Möglichkeit, CASCADE ON DELETE und CASCADE ON UPDATE zu definieren - um referenzielle Abhängigkeiten zu synchronisieren, ohne Einschränkungen zu deaktivieren.
Idealerweise möchten Sie einen natürlichen Schlüssel. Ein natürlicher Schlüssel sind vorhandene Daten, die die zu modellierende Entität eindeutig identifizieren. Zum Beispiel sind die Abkürzungen von US-Staaten ein guter natürlicher Schlüssel, weil die Abkürzung konsistent ist und jeder sie kennt:
%Vor%Versuchen Sie nicht zu sehr, einen natürlichen Schlüssel zu finden. Sie existieren selten. Es ist unwahrscheinlich, dass sich der Name eines US-Staates ändert, aber es ist plausibel.
Realistisch gesehen sind Primärschlüssel typischerweise künstlich (oft durch Datenbankfunktionalität erzeugt). Dies sind in der Regel Zahlen oder GUIDs, und sie werden als künstlich betrachtet, weil sie selbst - es gibt nichts, um ihren Wert mit den Informationen, die sie eindeutig identifizieren, in Beziehung zu setzen. Ein Kassenbeleg ist immer nummeriert, weil es nichts Natürliches gibt und auch für das Auditing - Lücken in den Belegnummern lassen Vermutungen aufkommen. Um zu demonstrieren, wie willkürlich Nummerierung ist, ist hier die US-State-Tabelle, aber eine Ganzzahl für die Primärschlüsselspalte, US_STATE_CODE:
%Vor%Es ist nicht erforderlich, den Wert auf eins zu setzen. Einige Shops nutzen dies als Sicherheitsmaßnahme, um SQL-Injection zu verhindern. Der Wert basiert auf der alphabetischen Reihenfolge des Statusnamens, kann jedoch nicht garantiert werden. Aber im Gegensatz zum natürlichen Schlüssel, wenn der Name des Status geändert wurde - nur eine Spalte müsste aktualisiert werden.
Idealerweise wird eine Spalte der Primärschlüssel sein, aber treffen Sie die Entscheidung basierend auf den vorliegenden Daten - kombinieren Sie Spalten nicht nur, um eine einzige Spalte zu haben. Wenn Sie Shoehorn-Daten zusammen verwenden, verwenden Sie ein Zeichen, um die Daten einfach zu trennen (obwohl Operationen, die dies tun, keinen Index nutzen können, falls vorhanden).
Aus Performance-Sicht sind Ganzzahlen am besten geeignet, da sie einen anständigen Wertebereich bieten und die Anzahl der verwendeten Bytes klein ist, wenn Sie VARCHAR mit fünf oder mehr Zeichen vergleichen.
Der Datenbankentwurf beginnt mit einem konzeptionellen Datenmodell (z. B. einem Entitätsbeziehungsdiagramm) und endet mit einem Datenbankschema oder -schemas. Entitäten werden Tabellen zugeordnet; In diesem Prozess kann eine Entität in mehrere Tabellen aufgeteilt werden, mehrere Entitäten können in einer einzigen Tabelle zusammengeführt werden, und es können neue Tabellen entstehen (zum Beispiel Kreuztabellen zur Implementierung von Viele-zu-Viele-Beziehungen).
In einer ERD Entitäten haben Primärschlüssel. Dies sind natürliche Schlüssel, dh sie sind Attribute der Entität. Für eine PERSON-Entität kann dies SocialSecurityNumber sein. Für eine ORDER-Entität, die möglicherweise OrderRef ist Für eine INVOICE-Entität könnte es sich um die Rechnungsnummer handeln. Im ersten Fall handelt es sich um eine reale Kennung. im zweiten Fall ist es ein intelligenter Schlüssel in einem hässlichen Format (2010 / DEF / 000023); Im dritten Fall handelt es sich um eine monoton steigende Zahl, da dies das aktuelle papierbasierte System ist.
Natürliche Schlüssel können phantasievoll sein. Ich habe einmal an einem Datenbankdesign gearbeitet, bei dem der Analyst die Entität KUNDE mit einem Schlüssel (FullName, Address, Sex, DateOfBirth, DistinguishingCharacteristics) auf der Basis angegeben hat, dass zwei Personen gleichen Namens, Geburtsdatum und Geschlecht gleichzeitig leben können Adresse.
Die Merkmale des Primärschlüssels einer Entität sind:
Wenn es um Primärschlüssel für Datenbanktabellen geht, sind natürliche Schlüssel nicht immer geeignet.
Es gibt viele Gründe, SSN nicht als physischen Primärschlüssel zu verwenden. Der Schutz der persönlichen Daten eines Bürgers ist eigentlich der wichtigste, aber es kann auch sein, dass sich die Nummer eines Bürgers ändert. Primärschlüssel sollten unverändert sein.
Intelligente Schlüssel sind dumm. Sie sind tatsächlich zusammengesetzte Schlüssel, die zu einer einzigen Spalte komprimiert sind. Sie werden besser als separate Spalten dargestellt, nicht zuletzt deshalb, weil häufig nach einzelnen Schlüsselelementen gesucht wird. Auch das Format solcher Schlüssel kann sich ändern.
Im Allgemeinen sind zusammengesetzte Schlüssel ein Schmerz als Primärschlüssel, weil wir mehrere Spalten als Fremdschlüssel kaskadieren müssen. Dies wird noch verschärft, wenn der Primärschlüssel des Kindes als Seriennummer innerhalb des Primärschlüssels des Elternteils definiert ist. Es gibt Systeme da draußen, deren abhängige Tabellen einen neunspaltigen Fremdschlüssel von einem Elternteil erben, wenn sie nur zwei eigene Datenspalten haben. Manchmal kann diese Art der Vererbung nützlich sein, aber meistens ist es nur ein Ärger.
Die Merkmale des Primärschlüssels einer Entität sind:
Wenn also der Kandidatenschlüssel kein bedeutungsloser Bezeichner ist (z. B. InvoiceNo), sollte eine Tabelle einen synthetischen Schlüssel (AKA-Ersatzschlüssel) haben. Dies kann eine monoton steigende Zahl oder eine GUID sein, je nach Ihren Bedürfnissen. Wenn es keine Schnittstellentabellen oder andere Attribute oder abhängige Tabellen gibt, gibt es keinen Wert beim Ersetzen eines zusammengesetzten Primärschlüssels (zusammengesetzter AKA-Schlüssel) durch einen synthetischen Schlüssel.
Entscheidend ist: Wir erzwingen immer noch die Kandidatenschlüssel . Das bedeutet, dass UNIQUE-Einschränkungen für diese Spalten - SSN, OrderRef - in der übergeordneten Tabelle angewendet werden. Dies liegt daran, dass ein synthetischer Schlüssel eine Zeile in einer Tabelle eindeutig identifiziert und die Daten nicht eindeutig identifiziert.
In Bezug auf Vertrautheit
Vertrautheit ist eine lockige. Es ist eine wichtige Überlegung, wenn es darum geht, Primärschlüssel in einem konzeptionellen Datenmodell zu identifizieren, aber es ist weniger nützlich, wenn es um Datenbankdesign geht.
In einem commnet bietet @bbadour zwei gegensätzliche Beispiele:
%Vor%und stellt die Frage:
"Was erreicht 3296013, wurde durch 840082470 nicht erreicht, was der primäre Schlüssel für meine akademischen Leistungen an irgendeiner oder jeder postsekundären Schule in Kanada ist."
Nun, 840082470 ist wie eine Rechnungsnummer. An sich ist es eine sinnlose Ziffernfolge. Wenn das System, das wir entwerfen, zur Domäne der kanadischen Hochschulbildung gehört, dann ist es sicherlich als Kandidat Schlüssel akzeptabel. Da es sich jedoch um einen Schlüssel handelt, der offensichtlich einem externen Zentralsystem gehört (verzeih mir, dass ich das kanadische akademische System nicht verstehe), sind einige der Einwände gegen SSN als Primärschlüssel offen. Wir sind auf dieses externe System angewiesen, um Einzigartigkeit zu gewährleisten, Stabilität zu garantieren und Identifikation zu verifizieren.
Was 745 gegen PE, CA angeht, ist das eindeutig falsch. Die kanadische postalische Abkürzung für "Prince Edward Island" und der ISO-Digraph für "Canada" identifizieren zwei unterschiedliche Informationen und stammen aus verschiedenen Quellen, daher sollten sie als zwei separate Spalten dargestellt werden. Aber konzentrieren wir uns darauf, ob 745 oder PE der bessere Primärschlüssel ist.
Als erstes ist es der Datenbank egal, welchen Datentyp wir verwenden, damit der Code "Prince Edward Island" darstellt. Es will nur garantierte Einzigartigkeit.
Als Zweites wird der dem Benutzer zugewandte Teil des Systems wahrscheinlich die vollständige Erweiterung "Prince Edward Island" anzeigen, in welchem Fall die Anwendung sowieso eine Suche ausführen muss. Dies liegt daran, dass Benutzer eines Systems, das auch Adressen aus dem Land Peru oder dem Bundesstaat Kalifornien besitzt, die Klarheit der erweiterten Namen zu schätzen wissen [1]. Sicherlich, wenn wir über die wenigen harten Fälle hinausgehen (wie z. B. Zustandsabkürzungen), sollte die Anwendung immer Codes erweitern, wenn sie Benutzern angezeigt werden.
Der einzige Vorteil der Verwendung von PE anstelle von 745 ist, dass Ad-hoc-Abfragen vereinfacht werden.
Drittens, wenn sich die Code-Erweiterung ändert, möchten wir vielleicht Datensätze unterscheiden, die die neuere Version verwenden. Dies ist viel einfacher, wenn 745='Prince Edward Island' und 746='Prince Edward Is.' , als wenn wir PE als Primärschlüssel verwenden.
Viertens, es gibt Überlegungen zur Programmierung. Wenn beispielsweise die Anwendungsentwickler Dropdown-Listen mit Java-Enumerationen bereitstellen müssen, benötigen sie numerische Codes.
Kurz gesagt, Vertrautheit mit natürlichen Schlüsseln ist nicht so nützlich wie die Praktikabilität von Ersatzschlüsseln.
[1] Kanadier werden wissen, dass CA für Kanada steht. Aber steht MO für Marokko, Monaco, Moldawien, Montenegro, die Mongolei oder Montserrat? Eigentlich keiner von ihnen: Es ist Macau.
Ein Kandidatenschlüssel ist eine Menge von Attributen, die irreduzibel eindeutig sind (irreduzibel bedeutet, dass kein Attribut aus dem Schlüssel entfernt werden kann, ohne die Eindeutigkeitseigenschaft zu verlieren).
Andere Kriterien bei der Auswahl der zu implementierenden Kandidatenschlüssel: Einfachheit, Stabilität, Vertrautheit.
Diese drei Kriterien sind wichtige Überlegungen, aber nicht notwendigerweise wesentliche Eigenschaften eines Schlüssels. Zum Beispiel kann es wünschenswert und ziemlich vernünftig sein, einen Schlüssel durchzusetzen, der sich oft ändern kann. Beispiel: Ein Benutzeranmeldename muss eindeutig sein, aber der Benutzer kann ihn beliebig ändern, solange er eindeutig ist.
Ein Primärschlüssel ist ein Kandidatenschlüssel.
Ein Primärschlüssel ist ein Schlüssel, der eine Entität eindeutig identifiziert. Wenn Sie einen Primärschlüssel auswählen, ist die beste Wahl fast immer ein Ersatzschlüssel, der überhaupt nichts mit der Entität zu tun hat, außer der eindeutigen Identifizierung.
Und das ist es. Es gibt angeblich seltene Fälle, in denen ein Primärschlüssel ein natürlicher Schlüssel sein könnte, aber ich habe noch nie einen gültigen gefunden.
Die meisten von uns verwenden eine 32-Bit-Autoinkrement-Ganzzahl als Primärschlüssel. Eine weitere ausgezeichnete Wahl (unter bestimmten Umständen) ist eine UUID.
Hey. es ist wieder offen. Hier geht's.
(1) Wählen Sie gute Kandidatenschlüssel.
Es gehört nicht zum Datenbank-Designer, Kandidatenschlüssel zu wählen. Der Datenbank-Designer hat die Verantwortung dafür zu sorgen, dass alle Eindeutigkeitsanforderungen, die ihm vom Benutzer mitgeteilt werden, werden durchgesetzt. Es ist also der Benutzer, der die Kandidatenschlüssel wählt.
Es gibt zwei Szenarien, die ich mir vorstellen kann, die das eindeutig lösen Position ein wenig.
Eins ist, wenn der Benutzer sagt, dass ein Attribut vom Typ 'Video' oder 'Audio' (oder einige solcher) soll einzigartig sein. Es kann unmöglich sein, sie tatsächlich durchzusetzen und es liegt in der Verantwortung des Designers, darauf hinzuweisen Benutzer (da es auch seine Verantwortung ist, auf die Einzigartigkeit von Audio- und Video-Inhalte sind ein sehr umstrittenes Thema, und das alles Eindeutigkeit bei solchen Attributwerten, selbst wenn sie vom System durchsetzbar ist, hat immer noch eine gute Chance, nicht die gleiche Einzigartigkeit wie der Benutzer zu sein will).
Zweitens wird das Bild durch die Möglichkeit des Unterscheidens verdüstert logische Designs, die alle das gleiche Problem ansprechen. Wenn D1 und D2 beide sind gültige Designs, die das gleiche Problem ansprechen, dann könnte es der Fall sein Eine bestimmte gegebene Eindeutigkeitsregel, die vom Benutzer auferlegt wird, ist durchführbar Schlüssel in D1, aber nicht in D2. Aus dieser Perspektive, "Auswahl des Kandidaten Schlüssel "können interpretiert werden als" ein bestimmtes Design so wählen, dass a Die gegebene Eindeutigkeitsregel ist mit Schlüsseln erzwingbar. "Aber das war nicht wirklich die Frage, die du gestellt hast.
(2) Wählen Sie gute Primärschlüssel.
Vor einiger Zeit hat Darwen die Frage gestellt: "Was sind gute Gründe für eine Single? einen bestimmten Kandidaten als "primär" ausweisen? ". Es ist nicht viel herausgekommen, außer vielleicht: "um dies vorzuschlagen Ein besonderer Schlüssel ist der bevorzugte Schlüssel, wenn Referenzen verwendet werden diese relvar. "Ich vermute, dass sie nicht überzeugend genug gefunden haben, um sich zu ändern ihre frühere Entscheidung, dass "kein Schlüssel einzigartiger ist als jeder andere".
Aber vorausgesetzt, dass es dennoch einen gültigen Grund für die Single gibt einen bestimmten Schlüssel als "primär" aus, nehme ich folgendes an Überlegungen gelten:
Ihre Antwort an Erwin: "Ich stimme zu, dass die Auswahl eines Primärschlüssels lediglich einen Kandidatenschlüssel als bevorzugt für Fremdschlüsselreferenzen bezeichnet. Jedoch müssen Designer, selbst wenn wir den Namen" Primärschlüssel "vollständig eliminieren, immer noch wählen, welcher Kandidatenschlüssel sich zu Referenzzwecken in eine andere Beziehung ausbreitet. Wenn Benutzer eine stark referenzierte Beziehung mit einem instabilen, zusammengesetzten Schlüssel identifizieren, beabsichtigen Sie zu implizieren, dass der Designer kein Geschäft hat, einen zusätzlichen einfachen, stabilen Schlüssel zu wählen oder den einfachen, stabilen Schlüssel für die Beziehung zu verwenden? das zu unterstellen - bbadour vor 8 Stunden "
Ihre ursprüngliche Frage lautete "Primärschlüssel". Jetzt ändern Sie Ihren Fokus auf Schlüssel und Fremdschlüssel. Ein Schlüssel ist eine Integritätsbedingung. Das einzige Kriterium ist, dass ein minimaler Satz von Attributen in einer Relation eindeutig sein muss (Eindeutigkeit und Irreduzibilität). Wenn wir unseren Fokus auf Fremdschlüssel setzen, dann sind Einfachheit, Stabilität und Vertrautheit die Kriterien, um aus allen Kandidatenschlüsseln in der referenzierten Beziehung auszuwählen. Es könnte mehr Kandidatenschlüssel geben, die diese Kriterien mehr oder weniger in gleichem Maße erfüllen. Wenn wir uns die Vertrautheit ansehen, könnte ein Kandidatenschlüssel einer Gruppe von Benutzern sehr vertraut sein und nicht einer anderen Gruppe, für die ein anderer Kandidatenschlüssel vertrauter ist. Denken Sie über verschiedene Ansichten oder Subschemas einer Datenbank nach. Diese zweite Gruppe von Benutzern sollte einen anderen Kandidatenschlüssel als Referenzschlüssel (als Fremdschlüssel) auswählen. Wenn Sie auf Primärschlüssel bestehen, von denen wir nur einen pro Relation haben, dann muss ich fragen, was einen Schlüssel primärer macht als andere. Ich denke, der Begriff Primärschlüssel sollte nicht verwendet werden. Zumindest auf der logischen Ebene. Auch der Begriff "Fremdschlüssel" ist nicht gut gewählt (Fremdschlüssel sind keine Schlüssel, sondern Referenzen).
Also, ich denke, die Erwin-Erwähnungen über "primäre" Schlüssel waren sehr auf den Punkt. Oder zumindest das war meine Interpretation dessen, was er meint.
Stimmen Sie damit überein? Wenn ja, würden Sie Ihre ursprüngliche Frage in "Was sind die Entwurfskriterien für Schlüssel und was sind die Kriterien, um einen Fremdschlüssel aus den verfügbaren Kandidatenschlüssel wählen?" Zu ändern? Wenn nicht, warum?
Grüße, Carlos
Ein Primärschlüssel ist ein Kandidatenschlüssel, der für eine spezielle Behandlung ausgewählt wurde. Zuerst müssen wir uns die Eigenschaften von Kandidatenschlüsseln ansehen. Ein Satz aus einer oder mehreren Spalten ist ein Kandidatenschlüssel, wenn er die folgenden zwei Eigenschaften aufweist:
Eindeutigkeit: Ein Kandidatenschlüssel muss jede Zeile in einer Tabelle eindeutig identifizieren. Keine Tabelle darf zwei Zeilen mit demselben Wert für den Kandidatenschlüssel enthalten.
Irreducability: Das Entfernen einer Spalte aus einem Kandidatenschlüssel muss gegen die uniqness-Eigenschaft verstoßen. Mit anderen Worten, keine Teilmenge von Spalten in einem Kandidatenschlüssel ist selbst ein Kandidatenschlüssel.
Wenn kein Kandidatschlüssel existiert und manchmal sogar ein solcher, wird oft ein Ersatzschlüssel unter Verwendung einer automatisch inkrementierenden Ganzzahlspalte oder unter Verwendung einer anderen Technik erstellt. Dieser Ersatzschlüssel ist jetzt auch ein Kandidatenschlüssel.
Es ist oft nützlich, unter den verfügbaren Kandidatenschlüsseln zu wählen und einen davon als Primärschlüssel zu bestimmen. Das erste häufig angewandte Kriterium ist die Einfachheit, die den Kandidatenschlüssel mit den wenigsten Spalten angibt. Es gibt jedoch andere mögliche Kriterien, wie Vertrautheit, vertraute Werte, die nützlicher sind als nicht vertraute Werte, und Stabilität, wobei stabile Schlüssel weniger problematisch sind als Schlüssel, die dazu neigen, sich zu ändern. Diese Kriterien sind jedoch streng außerhalb des Geltungsbereichs des relationalen Modells, stehen oft in Konflikt zueinander und werden oft gemacht, um mit Implementierungsbeschränkungen fertig zu werden.
Ich würde sagen, dass die ersten beiden Konzepte "Eindeutigkeit" und "Irreduzibilität" weniger Designkriterien sind als grundlegende Eigenschaften von Primärschlüsseln, während die letzteren Konzepte von "Einfachheit", "Vertrautheit" und "Stabilität" besser als Design bezeichnet werden Kriterien, da sie Kompromisse und Subjektivität beinhalten.
Warum wählen Sie einen Primärschlüssel? Einfachheit und Vertrautheit sind nicht nur Kriterien für die Auswahl unter den verfügbaren Candidatenschlüsseln, sondern auch, warum wir überhaupt einen Primärschlüssel wählen sollten. Wenn es mehrere Kandidatenschlüssel in einer Tabelle gibt, vereinfacht dies Dinge, wenn alle Fremdschlüssel, die auf diese Tabelle verweisen, sich auf den gleichen Kandidatenschlüssel beziehen. Darüber hinaus wird die Wahl eines bestimmten Kandidatenschlüssels dazu beitragen, dass er bekannt wird.
Was sind die Kriterien?
A PRIMARY KEY definiert die Entity, nur die Entity und nichts als die Entity.
Sie können es von der Außenwelt nehmen. Sagen wir, eine Sternkatalognummer, um einen Stern zu identifizieren (gutes Beispiel), oder ein SSN , um eine Person zu identifizieren (schlechtes Beispiel).
In diesem Fall verlassen Sie sich auf die Außenwelt.
SSN ? (Sie nicht). SSN einzigartig? (Sie sind nicht). SSN einer anderen Person zugewiesen werden? (Es kann). Sie können es in Ihrem Modell mit AUTOINCREMENT oder GUIDs oder was auch immer erstellen.
In diesem Fall verlassen Sie sich auf sich und Ihre Datenbankfähigkeiten.
ID ? (Ja, das tun sie, sonst wären sie nicht in der Tabelle mit ID NOT NULL ). ID's eindeutig? (Ja, sie sind, die PRIMARY KEY Einschränkung kümmert sich darum). Oder eine andere Reihe von Antworten:
ID ? (Nein, sie nicht, der People-Tisch wurde versehentlich fallengelassen, obwohl einige andere Informationen beibehalten wurden.) ID's eindeutig? (Nein, zwei Versionen der Datenbank konnten nicht ordnungsgemäß zusammengeführt werden.) AUTOINCREMENT versehentlich zurückgesetzt). Das Wichtigste ist, dass ein Ersatzschlüssel ein Fest ist, das immer bei dir ist. Sie können immer einen Ersatzschlüssel erstellen: Nichts auf der Erde kann Sie davon abhalten, ein AUTOINCREMENT -Feld zu deklarieren. Aber bei weitem nicht alle Dinge haben eine Art Bezeichner, auf den sich alle einigen.
Allerdings kann ein guter natürlicher Schlüssel nicht genug betont werden.
Guide Star Catalog -Datenbank wird höchstwahrscheinlich zuverlässiger als Ihre und die Liste der US -Zustandscodes, die Sie immer direkt aus dem Speicher wiederherstellen können, gesichert.
(Nicht ganz sicher, wie man diese Frage interpretiert. Klingt wie ein Quiz oder etwas, wo man nach einer einzigen "richtigen" Antwort aus einem Lehrbuch sucht. Ich werde die Frage als eine praktischer interpretieren, daher meine Rat unten.)
Zumindest in der MS SQL-Welt ist die Diskussion über einen richtigen Primärschlüssel zwangsläufig in Diskussionen über den richtigen Clustered-Index für eine Tabelle eingebunden. Die beiden haben nicht , um gleich zu sein, aber sie sind standardmäßig, und für viele Tabellen ist es oft eine gute Idee, die beiden gleich zu machen.
Für die Zwecke unserer Diskussion hier ist es wichtig, zwischen den beiden zu unterscheiden:
Ein PRIMARY KEY ist ein Feld oder eine Kombination von Feldern, die eine Zeile eindeutig identifizieren.
Ein CLUSTERED INDEX ist ein Feld oder eine Kombination von Feldern, das die physische Reihenfolge einer Tabelle darstellt. (Noch einmal, ich spreche über MS SQL Server, nicht sicher, wie andere RDBS damit umgehen könnte)
Der Schlüssel für den Rest meiner Diskussion ist, dass seit SQL 7.0 der -clustered-Indexschlüssel als Zeilenbezeichner für alle nicht gruppierten Indizes verwendet wird. Dies bedeutet, dass viele der gleichen Kriterien für die Auswahl eines guten Clustering-Schlüssels dieselben sind wie für die Auswahl eines guten Primärschlüssels.
Sehen wir uns zuerst die Kriterien für einen guten Clustered-Index an (Von Kimberly Tripps exzellenter Artikel ). Ein gruppierter Index sollte lauten:
Es ist leicht ersichtlich, dass die ersten 3 auch gute Kriterien für einen Primärschlüssel sind. # 4 ist ein Bonus, der die Tabellenfragmentierung reduziert, wenn Tabellen wachsen.
Eine GUID als Primärschlüssel, so beliebt wie diese, schlägt tatsächlich zwei dieser Kriterien (eng und stetig steigend). Daher wird es in den meisten Fällen nicht als PK / Clustered-Index empfohlen (siehe Kims verwandten Artikel hier )
Ich werde hier etwas sagen, was nicht erwartet wird.
Alles, was sie in der Datenbank über Normalisierung und Schlüssel lehren, ist falsch, wenn es darum geht, Primärschlüssel auszuwählen.
Der Primärschlüssel ist speziell, wenn es um Bereichsabfragen geht, und aus diesem Grund, wenn Sie eine dominante Bereichsabfrage haben, die Ihr Primärschlüssel ist, keine Ausnahmen.
Wenn sich Ihre dominante Bereichsabfrage nicht auf einem Kandidatenschlüssel befindet, erhalten Sie einen Primärschlüssel, der nicht für die Eindeutigkeit erzwungen wird! Dies wird manchmal als gruppierter Index bezeichnet, was eine falsche Bezeichnung ist, da kein Index vorhanden ist.
Jetzt sind die Normalisierungs- und Kandidatenschlüssel wichtig, und Sie werden für einige von ihnen eindeutige Einschränkungen erzwingen wollen. Ordnen Sie den Primärschlüssel jedoch nicht zu, da dies der natürliche Schlüssel ist. Tatsächlich ist dies langsamer als das Definieren eines Index und einer eindeutigen Einschränkung. Definieren Sie den Primärschlüssel nur basierend auf Bereichsabfragen.
Denken Sie daran, dass es keine Einschränkung für Primärschlüssel gibt. Eine Tabelle ohne Primärschlüssel wird als Heap-Tabelle bezeichnet und hat entweder keine intrinsische Reihenfolge oder die Reihenfolge der Insertionsreihenfolge.
EDIT: Definition der Bereichsabfrage:
Eine Bereichsabfrage ist eine Abfrage, bei der es sich um eine ORDER BY-Abfrage oder einen Operator größer als oder kleiner als enthält. Was uns interessiert, sind die Spalten, für die diese Abfragen ausgeführt werden. Die grundlegende Idee ist eine Bereichsabfrage, die mehrere (zehn bis Hunderte bis vielleicht Tausende, aber nicht alle) Zeilen aus der Tabelle basierend auf Begrenzungsbedingungen an einem oder beiden Enden abruft.
Es gibt eine andere Art von Bereichsabfragen, und hier haben Sie einen Fremdschlüssel für eine andere Tabelle und eine Operation wählt alle Übereinstimmungen für diesen Fremdschlüssel aus. Dies ist in der Tat auch eine Bereichsabfrage, wenn auch nicht offensichtlich.
Tags und Links database primary-key database-design foreign-keys data-modeling