Primärschlüssel und Fremdschlüssel sind der Klebstoff, der mehrere Tabellen in einer effizienten relationalen Datenbank organisiert. Die Gestaltung von Primärschlüsseln und Fremdschlüsseln hat entscheidenden Einfluss auf die Leistung und Verfügbarkeit der physischen Datenbank.
Das Datenbankschema muss von einem theoretischen logischen Entwurf in einen tatsächlichen physischen Entwurf umgewandelt werden. Die Struktur von Primärschlüsseln und Fremdschlüsseln ist der Kern dieses Entwurfsprozesses. Sobald die entworfene Datenbank in einer Produktionsumgebung verwendet wird, wird es schwierig sein, diese Schlüssel zu ändern. Daher ist es sehr notwendig und lohnenswert, die Primärschlüssel und Fremdschlüssel während der Entwicklungsphase zu entwerfen.
Primärschlüssel:
Relationale Datenbanken basieren auf Primärschlüsseln – dem Eckpfeiler des physischen Schemas der Datenbank. Primärschlüssel haben auf der physischen Ebene nur zwei Zwecke:
1. Identifizieren Sie eine Zeile eindeutig.
2. Als Objekt, auf das durch Fremdschlüssel effektiv verwiesen werden kann.
Basierend auf den beiden oben genannten Verwendungszwecken sind hier einige Prinzipien, die ich beim Entwerfen von Primärschlüsseln auf physischer Ebene befolge:
1. Der Primärschlüssel sollte für den Benutzer bedeutungslos sein. Wenn ein Benutzer Daten in einer Join-Tabelle sieht, die eine Viele-zu-Viele-Beziehung darstellen, und sich darüber beschwert, dass sie von geringem Nutzen sind, beweist das, dass sein Primärschlüssel gut entworfen ist.
2. Der Primärschlüssel sollte eine einzelne Spalte sein, um die Effizienz von Verknüpfungs- und Filtervorgängen zu verbessern.
Hinweis: Personen, die zusammengesetzte Schlüssel verwenden, entschuldigen sich normalerweise aus zwei Gründen, die beide falsch sind. Einer davon ist, dass der Primärschlüssel eine tatsächliche Bedeutung haben sollte. Die Bedeutung des Primärschlüssels bietet jedoch nur eine praktische Möglichkeit, die Datenbank künstlich zu zerstören. Zweitens können Sie mit dieser Methode zwei Fremdschlüssel als Primärschlüssel in einer Join-Tabelle verwenden, die eine Viele-zu-Viele-Beziehung beschreibt. Ich bin auch aus folgenden Gründen gegen diesen Ansatz: Zusammengesetzte Primärschlüssel führen zu fehlerhaften Fremdschlüsseln. Das heißt, wenn Tabellen verbunden werden Werden Sie zur Mastertabelle einer anderen Slave-Tabelle und werden Sie gemäß der zweiten Methode oben Teil des Primärschlüssels dieser Tabelle. Diese Tabelle kann jedoch zur Mastertabelle anderer Slave-Tabellen und zu deren Primärschlüssel werden kann als Teil des Primärschlüssels zur Mastertabelle anderer Slavetabellen werden. Bei dieser Weitergabe gilt: Je später die Slavetabelle, desto mehr Spalten enthält ihr Primärschlüssel.
3. Aktualisieren Sie niemals Primärschlüssel. Da der Primärschlüssel keinen anderen Zweck hat als die eindeutige Identifizierung einer Zeile, gibt es keinen Grund, ihn zu aktualisieren. Wenn der Primärschlüssel aktualisiert werden muss, wird der Grundsatz verletzt, dass der Primärschlüssel für den Benutzer bedeutungslos sein sollte.
Hinweis: Dieses Prinzip gilt nicht für Daten, die häufig während der Datenkonvertierung oder der Zusammenführung mehrerer Datenbanken organisiert werden müssen.
4. Der Primärschlüssel sollte keine sich dynamisch ändernden Daten wie Zeitstempel, Erstellungszeitspalte, Änderungszeitspalte usw. enthalten.
5. Der Primärschlüssel sollte automatisch vom Computer generiert werden. Wenn ein Mensch in die Erstellung eines Primärschlüssels eingreift, hat dieser eine andere Bedeutung als die eindeutige Identifizierung einer Zeile. Sobald diese Grenze überschritten wird, besteht möglicherweise ein Anreiz, den Primärschlüssel zu ändern, sodass die von diesem System zum Verknüpfen und Verwalten von Datensatzzeilen verwendeten Schlüsselmittel in die Hände von Personen fallen, die sich mit dem Datenbankdesign nicht auskennen.
Ein Fremdschlüssel ist eine Integritätsbeschränkung auf Datenbankebene. Dies ist die Datenbankimplementierungsmethode der „referenziellen Integrität“, die im Buch zur grundlegenden Datenbanktheorie erwähnt wird.
Natürlich kann das Fremdschlüsselattribut entfernt werden, wenn Sie diese Einschränkung nicht mehr verwenden möchten, hat dies sicherlich keine Auswirkungen auf die Programmierung, aber bei der Eingabe von Daten wird die Prüfung der „referenziellen Integrität“ nicht auf die eingegebenen Daten angewendet .
Beispielsweise gibt es zwei Tabellen
A(a,b): a ist der Primärschlüssel, b ist der Fremdschlüssel (von Bb)
B(b,c,d): b ist der Primärschlüssel
Wenn ich das Fremdschlüsselattribut von Feld b entferne, hat dies keine Auswirkungen auf die Programmierung.
Wie oben ist b in A entweder leer oder ein Wert, der in b in B vorhanden ist. Wenn ein Fremdschlüssel vorhanden ist, prüft die Datenbank automatisch, ob b in A in b in B vorhanden ist.
1. Externer Ausdruck drückt referenzielle Integrität aus: Diese ist den Daten inhärent und hat nichts mit dem Programm zu tun. Daher sollte es dem DBMS überlassen werden.
2. Die Verwendung externer Datenbanken ist einfach und intuitiv und kann sich direkt im Datenmodell widerspiegeln. Dies hat große Vorteile in Bezug auf Design, Wartung usw., insbesondere bei der Analyse vorhandener Datenbanken. Die Vorteile liegen auf der Hand – ich habe es nicht analysiert Vor langer Zeit habe ich eine vorhandene Unternehmensdatenbank gefunden. Einige der darin enthaltenen referenziellen Integritätsbeschränkungen werden durch Fremdschlüssel beschrieben, andere werden mithilfe von Triggern implementiert. Natürlich kann es im Dokument sein, aber es ist möglicherweise nicht vollständig, aber Fremdschlüssel sind sehr offensichtlich und intuitiv.
3. Da wir Trigger oder Programme verwenden können, um diese Arbeit abzuschließen (in Bezug auf Einschränkungen der referenziellen Integrität), hat DBMS die Mittel bereitgestellt. Warum sollten wir dies selbst tun? Und es sollte gesagt werden, dass das, was wir tun, nicht so gut ist wie RDBMS. Tatsächlich hatten die frühen RDBMS keine Fremdschlüssel, aber jetzt haben sie alle meiner Meinung nach, dass es für Datenbankanbieter sinnvoll ist, diese Funktion hinzuzufügen. Aus dieser Perspektive sind Fremdschlüssel bequemer.
4. Was die Benutzerfreundlichkeit anbelangt, so berichteten die Programmierer auf der Grundlage der von mir geleiteten Projekte, dass die Eingabe von Daten während des Debuggens hauptsächlich mühsam war: Wenn die Daten die referenzielle Integrität verletzen können, steht die referenzielle Integrität selbst derzeit nicht im Widerspruch zum Reputationsgeschäft. Andernfalls sollte das Trigger-Futures-Programm nicht verwendet werden. Dies bedeutet, dass die Daten falsch sind und überhaupt nicht in die Datenbank eingegeben werden sollten! Darüber hinaus sollte dies auch Teil des Testsystems sein: die Sperrung illegaler Daten. Tatsächlich sollte das Front-End-Programm diesen Übermittlungsfehler behandeln. Daten gehören dem Unternehmen, nicht dem Programm. Gespeicherte Programme sollten so weit wie möglich von den Daten getrennt werden und umgekehrt.
Lassen Sie mich abschließend über einige Prinzipien für die Schlüsselerstellung sprechen:
1. Erstellen Sie Fremdschlüssel für verwandte Felder.
2. Alle Schlüssel müssen eindeutig sein.
3. Vermeiden Sie die Verwendung zusammengesetzter Schlüssel.
4. Fremdschlüssel sind immer eindeutigen Schlüsselfeldern zugeordnet.
Dieser Artikel stammt aus dem CSDN-Blog. Bitte geben Sie beim Nachdruck die Quelle an: http://blog.csdn.net/c04s31602/archive/2009/12/30/5107568.aspx