Es ist eine ziemlich allgemeine Frage, aber ich würde gerne wissen, was Sie bei der Bestimmung des Primärschlüssels der Tabelle verwenden. Beispiele, die Sie mit Begründung erhalten, sind sehr erwünscht.
Ich habe bemerkt, dass viele Programmierer die ID-Spalte hinzufügen und sie als Primärschlüssel verwenden. Ich denke, es ist vom Design her fehlerhaft, da die ID in diesem Fall nichts mit der Tabelle zu tun hat.
Mein Denkprozess bei der Bestimmung eines Primärschlüssels geht so.
"Ein Datensatz in dieser Tabelle steht für ...?"
"Für verschiedene Werte von Col X, Col Y, Col Z ... sollte es nur eine Zeile in der Tabelle geben." Was sind Cols X Y und Z? "
Die Tabelle CAR_MODEL.
Hmm diese Tabelle wird Informationen über verschiedene Arten von Autos speichern, sollte der MANUFACTURER_NAME der Schlüssel sein? Nein, ich kann viele Reihen haben, die verschiedene Automodelle vom selben Hersteller identifizieren. Hmmm sollten MANUFACTURER_NAME und MODEL_NAME der Schlüssel sein? Nein, ich möchte verschiedene Zeilen mit denselben MANUFACTURER_NAME- und MODEL_NAME-Tags, aber unterschiedlichen Versionsjahren in der Tabelle gleichzeitig haben. Ok, was ist mit "MANUFACTURER_NAME", "MODEL_NAME" und "RELEASE_YEAR".
Ist es mir möglich, zwei Zeilen gleichzeitig mit MANUFACTURER_NAME, MODEL_NAME und RELEASE_YEAR zu haben? Hmmm nein. Das würde keinen Sinn ergeben, sie wären das gleiche Automodell, und ich möchte nur 1 Rekord pro Automodell. Großartig, das ist der Schlüssel.
Ein Datensatz in dieser Tabelle repräsentiert ein bestimmtes Modell eines bestimmten Jahres eines bestimmten Herstellers. Ich entscheide dies, wenn ich die Tabelle erstelle, deshalb habe ich die Tabelle erstellt, wenn Sie nicht beschreiben können, was in der Tabelle steht, um den Schlüssel zu identifizieren, den Sie nicht wirklich verstehen, warum Sie ihn erstellen.
Schreckliche Veränderungen im Laufe der Zeit !!! (Ersatzschlüssel, Natural Key, sich langsam ändernde Dimensionen)
Ah, aber die Informationen, die ich über ein bestimmtes Automodell (von einem bestimmten Hersteller und Release-Jahr) gespeichert habe, könnten sich ändern. Anfangs wurde mir gesagt, dass es zwei Türen hat, jetzt finde ich, dass es vier hat. Ich möchte diese korrekte Information in meiner Tabelle haben, aber nicht die alten Aufzeichnungen verlieren, da die Leute davon berichtet haben und ich ihre alten Ergebnisse reproduzieren muss .
Ok, ich werde eine neue Spalte "MODEL_ID" hinzufügen und sie zum Primärschlüssel der Tabelle machen, so dass ich mehrere Datensätze mit demselben Modellnamen, Herstellernamen und Erscheinungsjahr speichern kann. Ich werde auch einen valid_from und valid_to Zeitstempel hinzufügen.
Das kann gut funktionieren, und tatsächlich ist der Primärschlüssel der Tabelle jetzt MODEL_ID, ein Ersatzschlüssel. Aber der Natural Key, der Business Key, der Schlüssel "zu jedem beliebigen Zeitpunkt" ist immer Model_Name, Manufacturer_Name und Release_Year, und ich kann das nicht aus den Augen verlieren.
Hinweis zu Ersatzschlüsseln :
Ein Ersatzschlüssel ist per Definition für jede Zeile eindeutig! Ein Ersatzschlüssel erleichtert die Manipulation von Daten, insbesondere von Daten, die sich im Laufe der Zeit ändern. Aber ein Ersatzschlüssel ersetzt in keiner Weise einen natürlichen Primärschlüssel, Sie müssen immer noch wissen, was das "Korn" der Tabelle ist.
Wenn wir sagen, dass jeder Person in Australien eine Stack_Overflow_User_id zugewiesen wird, was würden wir tun, wenn Jeff und Joel Stack_Overflow_User_Id's an Hunde und Katzen und mehrere IDs an die gleichen Leute vergeben würden?
Wir würden sagen: "Hey, Jeff und Joel, gib nur 1 ID pro Vornamen, Nachname, Geburtsdatum und Geburtsort aus!". *
Wir müssen den natürlichen Schlüssel kennen, oder wir können alles einen Ersatzschlüssel geben!
(* Was ist mit Menschen, wo alle gleich sind? Brauchen wir keine Passnummer oder irgendeine Art von Ersatz? In der Praxis ist ein Ersatz nett und sauber, aber woher kommt er? Ursprünglich kam er aus einem natürlichen Schlüssel.)
Die Rolle eines Primärschlüssels besteht darin, jede Zeile in Ihrer Tabelle eindeutig zu identifizieren. Wenn keine Spalte oder Spaltengruppe diese Anforderung erfüllt, wird oft eine Spalte mit einer eindeutigen ID als Primärschlüssel hinzugefügt.
Ich stimme Ihrem Kommentar zu Programmierern nicht zu, die eine ID hinzufügen, die nichts mit Tabellendaten zu tun hat. Wenn Sie Daten über mehrere Tabellen hinweg verknüpfen müssen, ist eine prägnante ID einfacher zu verwenden als ein zusammengesetzter Schlüssel.
Hollywood-Paare: Beziehungen sind härter als Sie denken ... einer meiner Favoriten.
Sie wählen alles aus, von dem Sie wissen, dass es sich um einen eindeutigen Wert handelt, vorzugsweise etwas Zahlenwert wie eine Kunden-ID oder Kontonummer. Finger weg von stringbasierten Schlüsseln, wenn es überhaupt möglich ist. Wenn nichts anderes, verwenden Sie einen GUID-Wert oder eine Auto-Inkrement-Ganzzahl.
Ein Schlüssel sollte eine Spalte sein, in der jeder Eintrag garantiert eindeutig ist. Beispiele können eine Sozialversicherungsnummer oder eine Führerscheinnummer sein. In der Theorie können Sie mehrere Spalten zu einem zusammengesetzten Schlüssel verknüpfen. Vielleicht könnten Name und Geburtsdatum also zusammen einzigartig sein, damit sie ein Schlüssel sein könnten. In der Praxis tut das niemand, weil das Überqueren von Tischen ein Schmerz ist. Die beste Lösung besteht normalerweise darin, einen autoinkrementierenden Wert oder eine GUID-Spalte hinzuzufügen.
Ein Primärschlüssel muss nicht unbedingt eine einzelne Spalte sein, sondern kann auch eine Kombination von Spalten sein. Wie sagt Altheracs Antwort Zweck ist, jede Zeile eindeutig zu identifizieren.
Aus Gründen der Performance ist es besser, einen kleinen Schlüssel zu haben, aber abhängig von den Anforderungen des Systems kann der verwendete Schlüsseltyp sehr unterschiedlich sein.
Alle Daten, die zur eindeutigen Identifizierung Ihres Eintrags benötigt werden, sollten Ihre Tabellen-ID sein. Wenn keine solchen Daten vorhanden sind, müssen Sie eine erstellen (am häufigsten wird eine laufende Nummer verwendet).
Ich stimme in Ihrem Punkt nicht überein, dass alle IDs etwas mit der Tabelle zu tun haben sollten, weil es manchmal nicht ausreicht, den Datensatz eindeutig zu identifizieren. Außerdem müssten Sie mehrere IDs verwenden, mit denen es viel schwieriger ist zu arbeiten als eine einfache laufende Nummer als ID.
Primärschlüssel sind relativ einfach für einzelne Tabellen, aber sobald Sie Ihre Einträge auf mehrere Tabellen verteilt haben, können die Dinge unordentlich werden, besonders bei vielen zu vielen Verbindungen. Die Arbeit mit Fremdschlüsseln muss ebenfalls durchdacht werden, bevor sie implementiert werden.
Wenn Sie professionell mit Datenbanken arbeiten möchten (oder dies nach dem Buch tun möchten), sollten Sie sich am besten mit vertraut machen Datenstrukturdiagramme
BEARBEITEN: Einheitliche Modellierungssprache sollte Ihnen helfen zu bestimmen, was als Primärschlüssel verwendet werden soll
Verwenden Sie natürliche Schlüssel überall dort, wo sie funktionieren und vertrauenswürdig sind. Wenn Sie Ihren Gegenstand in Entitäten und Beziehungen zwischen Entitäten (ER) analysieren, sollten Sie Schlüssel entwickeln, die die Entitäten in den Daten selbst identifizieren. Wenn es eine Entität gibt, deren Identität in den Daten selbst verwechselt wird, erfinden Sie einen künstlichen Schlüssel (üblicherweise als Ersatzschlüssel bezeichnet). Die Erfindung eines Schlüssels ist der letzte Ausweg.
Wenn Sie Tabellen erstellen, beschreiben einige Tabellen Entitäten und andere beschreiben Beziehungen. Entitätstabellen erhalten denselben Schlüssel wie die Entität. Beziehungstabellen erhalten einen zusammengesetzten Schlüssel mit einer Komponente für jede Entität, die an der Beziehung teilnimmt. Einige Beziehungen werden keine eigene Tabelle bekommen (viele zu eins). Stattdessen werden sie durch Hinzufügen von Fremdschlüsseln zu vorhandenen Tabellen dargestellt, sodass sie keinen eigenen Primärschlüssel benötigen.
Dies wird Sie etwas langsamer machen im Vergleich zu erfundenen ID-Feldern für jede Tabelle. Aber es wird zu einem besseren Datenmanagement führen, was zu besseren Daten führt.
Nun, in einem der Systeme, die wir verwenden (und ich entworfen habe), hat jeder Benutzer einen automatisch inkrementierten Primärschlüssel als seine ID. Andere Tabellen, die mit diesem bestimmten Benutzer verwandt sind, verwenden ihre ID als ihren primären Schlüssel (obwohl offensichtlich nicht automatisch inkrementiert), so dass es bei richtiger Verwendung Sinn macht.
Theoretisch könnte jedes eindeutige Feld verwendet werden (z. B. Sozialversicherungsnummer, URL usw.), aber in der Praxis glaube ich nicht, dass es einen großen Nachteil bei der Verwendung einer automatisch generierten ID gibt. Zum Beispiel, ein verrückter Fehler macht eine doppelte SSN könnte für Ihre Daten katastrophal sein.
Der Primärschlüssel sollte immer eine Ganzzahl mit automatischer Erhöhung sein, die nicht mit Ihren Daten zusammenhängt.
Bearbeitet, um hinzuzufügen, dass GUIDs auch in Ordnung sind. Wichtig ist, dass der Schlüssel Ihre Daten nicht beschreibt. Wenn sich Ihre Daten also ändern, ist dies bei Ihrem PK nicht der Fall. Verwenden Sie immer ein ID-Feld.
Stellen Sie sich vor, dass Sie eine E-Mail als Primärschlüssel verwenden und der Benutzer dann seine E-Mail-Adresse ändert. Sie müssen diese Änderung dann auf jede verbundene Tabelle kaskadieren. Die Verwendung von echten Daten als PK macht keinen Sinn.
Stellen Sie es sich als eine mögliche eindeutige Kennung (einzelne oder mehrere Spalten) für Ihre Datensätze vor.
Denken Sie über Fingerabdrücke nach. Denkst du, sie sind einzigartig für ein Individuum; Es ist noch nicht bewiesen, aber es scheint sicher ein anständiger eindeutiger Identifikator zu sein, bis die Population so groß wird, dass Redundanz einschleicht. Gegenwärtig ist dies wie ein Primärschlüssel für Datensätze, die Sie identifizieren. [1 Spalte]
Wenn unsere Population explodiert und Fingerabdrücke ihre Schwächen zeigen, können wir Fingerabdrücke und Iris-Scans als einen viel stärkeren Primärschlüssel kombinieren. [2 Spalten]
Der Primärschlüssel ist in der Regel ein eindeutiges Design, z. B. eine ID-Nummer, die bei der Instanziierung des Datensatzes in unserer Datenbank angegeben wurde.
Zumindest hoffe ich, dass dies mit dem Konzept hilft.
Tags und Links sql mysql database-design