Ich baue eine kleine Anwendung und richte Fremdschlüsselbeziehungen zwischen Tabellen ein. Aber ich bin verwirrt, warum ich das wirklich brauche? Was ist der Vorteil - hilft es mir beim Schreiben meiner Abfragen, dass ich keine Joins durchführen muss? Hier ist ein Beispielausschnitt meiner Datenbank:
%Vor% Es besteht eine Schlüsselbeziehung zwischen users . user_id und projects . creator
Wäre ich in der Lage, eine Abfrage wie diese durchzuführen?
SELECT * FROM PROJECTS WHERE USERS.username = "a real user";
Da MySQL die Beziehung zwischen den Tabellen kennen sollte? Wenn nicht, was ist dann die wahre Funktion von Fremdschlüsseln in einem Datenbankentwurf?
Fremdschlüssel bieten referentielle Integrität. Die Daten in einer Fremdschlüsselspalte werden validiert - der Wert kann nur einer sein, der bereits in der Tabelle & amp; Spalte, die im Fremdschlüssel definiert ist. Es ist sehr effektiv, "schlechte Daten" zu stoppen - jemand kann nicht eingeben, was sie wollen - Zahlen, ASCII-Text, etc. Es bedeutet, dass die Daten normalisiert sind - wiederkehrende Werte wurden identifiziert und isoliert zu ihrer eigenen Tabelle, so dass es keine Bedenken mehr gibt über den Umgang mit Groß- / Kleinschreibung im Text ... und die Werte sind konsistent. Dies führt in den nächsten Teil - Fremdschlüssel sind das, was Sie verwenden, um Tabellen miteinander zu verbinden.
Ihre Abfrage nach Projekten, die ein Benutzer hat, würde nicht funktionieren. Sie verweisen auf eine Spalte aus der Tabelle USERS , wenn in der Abfrage kein Verweis auf die Tabelle vorhanden ist und keine Unterabfrage verwendet wird, um diese Informationen vor der Verknüpfung abzurufen es in die Tabelle PROJECTS . Was Sie wirklich verwenden würden, ist:
Im Grunde geben sie Ihnen keine Funktionalität mehr. Sie stoppen alle Einfügungen oder Aktualisierungen, die die referenzielle Integrität Ihres Datenmodells zerstören.
Ein weiterer wichtiger Aspekt meiner Meinung nach ist, dass sie das Datenmodell anderen Entwicklern, die es verwenden, mitteilen. Ich habe oft untersucht, welche Fremdschlüssel eine Tabelle hat, um zu sehen, wie das Datenmodell auf einen Blick zusammenpasst.
Wenn Sie keine Joins durchführen, benötigen Sie keine Fremdschlüssel.
Wenn Sie das nicht tun, brauchen Sie keine relationale Datenbank! (Kleiner Witz) Im Ernst, wenn Sie mehr als eine Tabelle haben, sollten Sie lernen, Joins zu verwenden und Fremdschlüssel in einem Schema zu entwerfen.
Wie frühere Bearbeiter gesagt haben, erzwingen Fremdschlüssel die referenzielle Integrität. Ohne referentielle Integrität erzeugen Joins mysteriöse Ergebnisse.
Meine frühere Antwort konnte die eigentliche Frage hinter der Frage nicht aufschreiben. Die Frage, die ich beantwortete, war: "Warum gibt es Fremdschlüssel in SQL-Schemas", und die Antwort ist "um Joins zu machen". Aber wenn ich die Frage noch einmal durchlese, verstehe ich eine viel subtilere Frage, nämlich "warum kann SQL nicht die Joins für mich machen, wenn es die Verknüpfungen kennt". Das ist eine wirklich gute Frage. Es verdient eine bessere Antwort als die oben genannten.
Eine Sprache, in der der Motor die Join-Bedingungen liefert, ist möglich. Man muss nur das grafische Abfrage-Design-Tool in Microsoft Access betrachten. Sobald Sie alle Intertable-Beziehungen zu Access deklariert haben, können Sie Daten aus mehreren Tabellen abrufen, ohne die Join-Bedingungen erneut anzugeben. Access erkennt sie automatisch.
Wenn man in Access eine Abfrage mit zwei Tabellen erstellt und dann in die SQL-Ansicht wechselt, sieht man, dass Access tatsächlich eine Verknüpfung mit einer Join-Bedingung erstellt hat. Eine solche Fähigkeit ist auch in zeichenbasierten Sprachen möglich, aber SQL ist keine solche Sprache.
Ich bemerke nebenbei, dass viele Projekte zu einem Benutzer gehören können. Also Benutzer ist die "Referenztabelle" im obigen Schema, nicht Projekte. Ich erwarte, dass die einfachere automatische Navigationsrichtung ein automatisches Nachschlagen aus einer Referenztabelle wäre, und nicht umgekehrt.
Die Verwendung einer Fremdschlüsseleinschränkung kann Folgendes bereitstellen:
Natürlich ist es nicht obligatorisch, eines dieser Dinge zu tun, aber wahrscheinlich wird die Codequalität im Laufe der Zeit verbessert. Es ist normalerweise gut, über Dinge strikt zu sein - es führt zu mehr Fehlern beim Testen (und daher weniger in der Produktion)
Wenn jeder Benutzer zu genau einem Projekt gehört und jedes Projekt genau einem Benutzer gehört, dann wird gesagt, dass die Tabellen eine Eins-zu-eins-Beziehung haben und eine Schlüsselbeziehung zwischen Benutzern hat.user_id und projects.project_id ist ok (wenn auch wahrscheinlich nicht Standard).
Wenn jedoch ein Benutzer zu vielen Projekten gehören kann (oder ein Projekt kann viele Benutzer haben), dann haben Sie eine Eins-zu-viele-Beziehung und Sie benötigen einen Fremdschlüssel.
Wenn Projekte viele Benutzer haben können und Benutzer zu vielen Projekten gehören können, dann haben Sie eine Beziehung von vielen zu vielen und Sie benötigen ein ausgefeilteres Modell.
Tags und Links sql mysql database database-design foreign-keys