Sind Fremdschlüssel in einem Datenbankdesign wirklich notwendig?

StackOverflow https://stackoverflow.com/questions/18717

  •  09-06-2019
  •  | 
  •  

Frage

Soweit ich weiß, werden Fremdschlüssel (FK) verwendet, um dem Programmierer dabei zu helfen, Daten korrekt zu manipulieren.Angenommen, ein Programmierer macht dies bereits richtig, brauchen wir dann wirklich das Konzept der Fremdschlüssel?

Gibt es andere Verwendungsmöglichkeiten für Fremdschlüssel?Vermisse ich hier etwas?

War es hilfreich?

Lösung

Fremdschlüssel tragen zur Durchsetzung der referenziellen Integrität auf Datenebene bei.Sie verbessern auch die Leistung, da sie normalerweise standardmäßig indiziert sind.

Andere Tipps

Fremdschlüssel können dem Programmierer auch dabei helfen, weniger Code zu schreiben, indem sie beispielsweise Folgendes verwenden: ON DELETE CASCADE.Das heißt, wenn Sie eine Tabelle mit Benutzern und eine andere mit Bestellungen oder Ähnlichem haben, kann das Löschen eines Benutzers automatisch alle Bestellungen löschen, die auf diesen Benutzer verweisen.

Ich kann mir nicht vorstellen, eine Datenbank ohne Fremdschlüssel zu entwerfen.Ohne sie werden Sie irgendwann einen Fehler machen und die Integrität Ihrer Daten beschädigen.

Sie sind nicht erforderlich, streng genommen, aber die Vorteile sind enorm.

Da bin ich mir ziemlich sicher FogBugz Es gibt keine Fremdschlüsseleinschränkungen in der Datenbank.Es würde mich interessieren, wie das funktioniert Fog Creek-Software Das Team strukturiert seinen Code, um sicherzustellen, dass es niemals zu Inkonsistenzen kommt.

Ein Datenbankschema ohne FK-Einschränkungen ist wie Fahren ohne Sicherheitsgurt.

Eines Tages wirst du es bereuen.Wenn Sie nicht so wenig zusätzliche Zeit mit den Designgrundlagen und der Datenintegrität verbringen, ist das ein sicherer Weg, später Kopfschmerzen zu bereiten.

Würden Sie Code in Ihrer Anwendung akzeptieren, der so schlampig wäre?Dadurch wurde direkt auf die Mitgliedsobjekte zugegriffen und die Datenstrukturen direkt geändert.

Warum wurde das Ihrer Meinung nach so schwierig gemacht? sogar inakzeptabel innerhalb moderner Sprachen?

Ja.

  1. Sie halten dich ehrlich
  2. Sie halten neue Entwickler ehrlich
  3. Du kannst tun ON DELETE CASCADE
  4. Sie helfen Ihnen dabei, schöne Diagramme zu erstellen, die die Verknüpfungen zwischen Tabellen selbst erklären

Persönlich bin ich für Fremdschlüssel, weil sie die Beziehung zwischen den Tabellen formalisieren.Mir ist klar, dass Ihre Frage voraussetzt, dass der Programmierer keine Daten einführt, die die referenzielle Integrität verletzen würden, aber ich habe viel zu viele Fälle gesehen, in denen die referenzielle Integrität von Daten trotz bester Absichten verletzt wurde!

Vor der Einführung von Fremdschlüsseleinschränkungen (auch bekannt als deklarative referenzielle Integrität oder DRI) wurde viel Zeit damit verbracht, diese Beziehungen mithilfe von Triggern zu implementieren.Die Tatsache, dass wir die Beziehung durch eine deklarative Einschränkung formalisieren können, ist sehr wirkungsvoll.

@John - Andere Datenbanken erstellen möglicherweise automatisch Indizes für Fremdschlüssel, SQL Server jedoch nicht.In SQL Server sind Fremdschlüsselbeziehungen nur Einschränkungen.Sie müssen Ihren Index für Fremdschlüssel separat definieren (was von Vorteil sein kann).

Bearbeiten:Ich möchte hinzufügen, dass die Verwendung von Fremdschlüsseln zur Unterstützung von ON DELETE oder ON UPDATE CASCADE meiner Meinung nach nicht unbedingt eine gute Sache ist.In der Praxis habe ich festgestellt, dass die Kaskade beim Löschen sorgfältig auf der Grundlage der Beziehung der Daten abgewogen werden sollte – z. B.Haben Sie ein natürliches über- und untergeordnetes Element, bei dem dies möglicherweise in Ordnung ist, oder handelt es sich bei der zugehörigen Tabelle um einen Satz von Nachschlagewerten?Die Verwendung kaskadierter Aktualisierungen bedeutet, dass Sie die Änderung des Primärschlüssels einer Tabelle zulassen.In diesem Fall habe ich eine allgemeine philosophische Meinungsverschiedenheit darüber, dass sich der Primärschlüssel einer Tabelle nicht ändern sollte.Schlüssel sollten von Natur aus konstant sein.

Angenommen, ein Programmierer macht dies bereits richtig

Eine solche Annahme zu machen, scheint mir eine äußerst schlechte Idee zu sein;Im Allgemeinen ist Software phänomenal fehlerhaft.

Und genau darum geht es.Entwickler können die Dinge nicht richtig machen, daher ist es eine gute Sache, dafür zu sorgen, dass die Datenbank nicht mit fehlerhaften Daten gefüllt wird.

Obwohl in einer idealen Welt natürliche Verknüpfungen Beziehungen verwenden würden (d. h.FK-Einschränkungen) anstelle übereinstimmender Spaltennamen.Dies würde FKs noch nützlicher machen.

Wie kann man ohne Fremdschlüssel feststellen, dass zwei Datensätze in unterschiedlichen Tabellen miteinander in Beziehung stehen?

Ich denke, was Sie meinen, ist die referenzielle Integrität, bei der der untergeordnete Datensatz nicht ohne einen vorhandenen übergeordneten Datensatz usw. erstellt werden darf.Diese werden oft als Fremdschlüsseleinschränkungen bezeichnet, dürfen jedoch nicht mit der Existenz von Fremdschlüsseln verwechselt werden.

Hat es einen Vorteil, keine Fremdschlüssel zu haben?Sofern Sie keine schlechte Datenbank verwenden, sind FKs nicht so schwer einzurichten.Warum sollten Sie sie also vermeiden?Es ist eine Sache, eine Namenskonvention zu haben, die besagt, dass eine Spalte auf eine andere verweist. Eine andere ist es, zu wissen, dass die Datenbank diese Beziehung tatsächlich für Sie überprüft.

Ich nehme an, Sie reden davon Von der Datenbank erzwungene Fremdschlüsseleinschränkungen.Sie verwenden wahrscheinlich bereits Fremdschlüssel, haben die Datenbank jedoch nicht darüber informiert.

Angenommen, ein Programmierer macht dies tatsächlich bereits auf die richtige Weise und brauchen wir dann wirklich das Konzept von Fremdschlüssel?

Theoretisch nein.Allerdings gab es noch nie eine Software ohne Fehler.

Fehler im Anwendungscode sind normalerweise nicht so gefährlich – Sie identifizieren den Fehler und beheben ihn, und danach läuft die Anwendung wieder reibungslos.Aber wenn ein Fehler es ermöglicht, dass fehlerhafte Daten in die Datenbank gelangen, dann bleiben Sie dabei hängen!Es ist sehr schwierig, beschädigte Daten in der Datenbank wiederherzustellen.

Überlegen Sie, ob ein subtiler Fehler vorliegt FogBugz erlaubte das Schreiben eines beschädigten Fremdschlüssels in die Datenbank.Es könnte einfach sein, den Fehler zu beheben und den Kunden den Fix in einer Bugfix-Version schnell zur Verfügung zu stellen.Doch wie sollen die beschädigten Daten in Dutzenden von Datenbanken repariert werden? Richtig Der Code könnte jetzt plötzlich kaputt gehen, weil die Annahmen über die Integrität von Fremdschlüsseln nicht mehr gelten.

In Webanwendungen kommuniziert normalerweise nur ein Programm mit der Datenbank, sodass es nur eine Stelle gibt, an der Fehler die Daten beschädigen können.In einer Unternehmensanwendung kann es mehrere unabhängige Anwendungen geben, die mit derselben Datenbank kommunizieren (ganz zu schweigen von Personen, die direkt mit der Datenbank-Shell arbeiten).Es gibt keine Möglichkeit, sicherzustellen, dass alle Anwendungen immer und für immer denselben Annahmen ohne Fehler folgen.

Wenn Einschränkungen in der Datenbank codiert sind, kann das Schlimmste, was bei Fehlern passieren kann, darin bestehen, dass dem Benutzer eine hässliche Fehlermeldung zu einigen angezeigt wird SQL Einschränkung nicht erfüllt.Das ist viel Dies ist besser, als beschädigte Daten in Ihre Unternehmensdatenbank zu lassen, wo sie wiederum alle Ihre Anwendungen beschädigen oder einfach zu allen möglichen falschen oder irreführenden Ausgaben führen.

Oh, und Fremdschlüsseleinschränkungen verbessern auch die Leistung, da sie standardmäßig indiziert werden.Mir fällt kein Grund ein nicht um Fremdschlüsseleinschränkungen zu verwenden.

FKs sind sehr wichtig und sollten immer in Ihrem Schema vorhanden sein. es sei denn, Sie sind eBay.

Ich finde eine einzelne Sache Irgendwann muss er dafür verantwortlich sein, gültige Beziehungen sicherzustellen.

Zum Beispiel, Ruby auf Schienen verwendet keine Fremdschlüssel, sondern validiert alle Beziehungen selbst.Wenn Sie immer nur über diese Ruby on Rails-Anwendung auf Ihre Datenbank zugreifen, ist das kein Problem.

Wenn Sie jedoch andere Clients haben, die in die Datenbank schreiben, müssen diese ohne Fremdschlüssel ihre eigene Validierung implementieren.Sie haben dann zwei Kopien des Validierungscodes, die höchstwahrscheinlich unterschiedlich sind, was jeder Programmierer als Todsünde erkennen sollte.

An diesem Punkt sind Fremdschlüssel wirklich notwendig, da sie es Ihnen ermöglichen, die Verantwortung wieder an einen einzigen Punkt zu verlagern.

Mit Fremdschlüsseln kann jemand, der Ihre Datenbank noch nicht gesehen hat, die Beziehung zwischen Tabellen bestimmen.

Jetzt mag alles in Ordnung sein, aber denken Sie darüber nach, was passieren wird, wenn Ihr Programmierer geht und jemand anderes übernehmen muss.

Fremdschlüssel ermöglichen es ihnen, die Datenbankstruktur zu verstehen, ohne Tausende von Codezeilen durchforsten zu müssen.

Soweit ich weiß, werden Fremdschlüssel verwendet, um dem Programmierer dabei zu helfen, Daten korrekt zu manipulieren.

FKs ermöglichen es dem DBA, die Datenintegrität vor dem Fummeln der Benutzer beim Programmierer zu schützen scheitert um dies zu tun, und manchmal auch zum Schutz vor der Fummelei von Programmierern.

Angenommen, ein Programmierer macht dies bereits richtig, brauchen wir dann wirklich das Konzept der Fremdschlüssel?

Programmierer sind sterblich und fehlbar.FKs sind deklarativ was es schwieriger macht, sie zu vermasseln.

Gibt es andere Verwendungsmöglichkeiten für Fremdschlüssel?Vermisse ich hier etwas?

Obwohl sie nicht aus diesem Grund erstellt wurden, bieten FKs starke und zuverlässige Hinweise für Diagrammtools und Abfrage-Builder.Dies wird an Endbenutzer weitergegeben, die dringend starke, zuverlässige Hinweise benötigen.

Sie sind nicht unbedingt notwendig, ebenso wie Sicherheitsgurte nicht unbedingt notwendig sind.Aber sie können Sie wirklich davor bewahren, etwas Dummes zu tun, das Ihre Datenbank durcheinander bringt.

Es ist so viel schöner, einen FK-Einschränkungsfehler zu debuggen, als einen Löschvorgang rekonstruieren zu müssen, der Ihre Anwendung kaputt gemacht hat.

Sie sind wichtig, da Ihre Anwendung nicht die einzige Möglichkeit ist, Daten in der Datenbank zu manipulieren.Ihre Anwendung geht möglicherweise so ehrlich mit der referenziellen Integrität um, wie sie möchte, aber alles, was es braucht, ist ein Trottel mit den richtigen Berechtigungen, der vorbeikommt und einen Einfüge-, Lösch- oder Aktualisierungsbefehl auf Datenbankebene ausgibt, und die gesamte Durchsetzung der referenziellen Integrität Ihrer Anwendung wird umgangen.Das Einfügen von FK-Einschränkungen auf Datenbankebene bedeutet, dass die FK-Einschränkung dazu führen wird, dass eine fehlerhafte Einfügungs-/Aktualisierungs-/Löschanweisung mit einer Verletzung der referenziellen Integrität fehlschlägt, sofern dieser Trottel sich nicht dafür entscheidet, die FK-Einschränkung zu deaktivieren, bevor er seinen Befehl ausgibt.

Ich denke über Kosten/Nutzen nach...In MySQL, das Hinzufügen einer Einschränkung ist eine einzelne zusätzliche Zeile von DDL.Es sind nur eine Handvoll Schlüsselwörter und ein paar Sekunden Bedenkzeit.Das sind meiner Meinung nach die einzigen „Kosten“ ...

Werkzeuge lieben Fremdschlüssel.Fremdschlüssel verhindern fehlerhafte Daten (d. h. verwaiste Zeilen), die möglicherweise keinen Einfluss auf die Geschäftslogik oder Funktionalität haben und daher unbemerkt bleiben und sich anhäufen.Es verhindert außerdem, dass Entwickler, die mit dem Schema nicht vertraut sind, ganze Arbeitsblöcke implementieren, ohne zu bemerken, dass ihnen eine Beziehung fehlt.Vielleicht ist im Rahmen Ihrer aktuellen Anwendung alles großartig, aber wenn Sie etwas übersehen haben und eines Tages etwas Unerwartetes hinzukommt (denken Sie an ausgefallene Berichte), befinden Sie sich möglicherweise an einer Stelle, an der Sie fehlerhafte Daten, die sich seit der Einführung angesammelt haben, manuell bereinigen müssen des Schemas ohne eine durch die Datenbank erzwungene Prüfung.

Die kurze Zeit, die Sie benötigen, um zu kodifizieren, was Ihnen bereits beim Zusammenstellen der Dinge im Kopf vorgeht, könnte Ihnen oder jemand anderem eine Menge Kummer Monate oder Jahre später ersparen.

Die Frage:

Gibt es noch andere Verwendungen für ausländische Schlüssel?Vermisse ich hier etwas?

Es ist etwas überladen.Fügen Sie anstelle von „Fremdschlüsseln“ Kommentare, Einrückungen oder Variablennamen ein ...Wenn Sie die betreffende Sache bereits perfekt verstehen, nützt es Ihnen nichts.

Entropiereduzierung.Reduzieren Sie das Risiko chaotischer Szenarien in der Datenbank.Es fällt uns schwer, alle Möglichkeiten in Betracht zu ziehen. Meiner Meinung nach ist die Entropiereduzierung der Schlüssel zur Aufrechterhaltung eines jeden Systems.

Wenn wir zum Beispiel eine Annahme treffen:Jede Bestellung hat einen Kunden, der die Annahme durchsetzen sollte etwas.In Datenbanken sind dieses „Etwas“ Fremdschlüssel.

Ich denke, dass dies den Kompromiss in Bezug auf die Entwicklungsgeschwindigkeit wert ist.Klar, man kann schneller programmieren, wenn sie ausgeschaltet sind, und das ist wahrscheinlich der Grund, warum manche Leute sie nicht verwenden.Persönlich habe ich damit einige Stunden totgeschlagen NHibernate und eine Fremdschlüsseleinschränkung, die wütend wird, wenn ich eine Operation ausführe.JEDOCH weiß ich, wo das Problem liegt, also ist es weniger problematisch.Ich verwende normale Tools und es gibt Ressourcen, die mir dabei helfen, das Problem zu umgehen, möglicherweise sogar Leute, die mir helfen!

Die Alternative besteht darin, zuzulassen, dass sich ein Fehler in das System einschleicht (und wenn genügend Zeit zur Verfügung steht, wird dies der Fall sein), wenn kein Fremdschlüssel festgelegt ist und Ihre Daten inkonsistent werden.Dann erhalten Sie einen ungewöhnlichen Fehlerbericht, untersuchen ihn und sagen „OH“.Die Datenbank ist kaputt.Wie lange wird es nun dauern, bis das Problem behoben ist?

Sie können Fremdschlüssel als eine Einschränkung betrachten, die

  • Helfen Sie dabei, die Datenintegrität aufrechtzuerhalten
  • Zeigen Sie, wie Daten miteinander in Beziehung stehen (was bei der Durchsetzung von Geschäftslogik und -regeln hilfreich sein kann)
  • Bei korrekter Verwendung kann es dazu beitragen, die Effizienz beim Abrufen der Daten aus den Tabellen zu steigern.

Wir verwenden derzeit keine Fremdschlüssel.Und größtenteils bereuen wir es nicht.

Allerdings werden wir sie in naher Zukunft aus mehreren Gründen wahrscheinlich häufiger nutzen, beide aus ähnlichen Gründen:

  1. Diagrammerstellung.Es ist viel einfacher, ein Diagramm einer Datenbank zu erstellen, wenn Fremdschlüsselbeziehungen korrekt verwendet werden.

  2. Werkzeugunterstützung.Es ist viel einfacher, Datenmodelle damit zu erstellen Visual Studio 2008 das man dafür verwenden kann LINQ to SQL ob ordnungsgemäße Fremdschlüsselbeziehungen vorhanden sind.

Ich denke, mein Punkt ist, dass wir herausgefunden haben, dass Fremdschlüssel nicht unbedingt erforderlich sind, wenn wir viel manuelle SQL-Arbeit durchführen (Abfrage erstellen, Abfrage ausführen, blablablabla).Sobald Sie jedoch anfangen, Tools zu verwenden, werden sie viel nützlicher.

Das Beste an Fremdschlüsseleinschränkungen (und eigentlich an Einschränkungen im Allgemeinen) ist, dass Sie sich beim Schreiben Ihrer Abfragen darauf verlassen können.Viele Abfragen können viel komplizierter werden, wenn Sie sich nicht darauf verlassen können, dass das Datenmodell „wahr“ ist.

Im Code wird im Allgemeinen irgendwo eine Ausnahme ausgelöst – aber in SQL, bekommen wir im Allgemeinen nur die „falschen“ Antworten.

In der Theorie, SQL Server könnte Einschränkungen als Teil eines Abfrageplans verwenden – aber abgesehen von Prüfeinschränkungen für die Partitionierung kann ich nicht sagen, dass ich das jemals tatsächlich gesehen habe.

Fremdschlüssel wurden in Projekten (Geschäftsanwendungen und Websites für soziale Netzwerke), an denen ich gearbeitet habe, nie explizit deklariert (Tabelle (Spalte) FOREIGN KEY REFERENCES).

Aber es gab immer eine Art Konvention zur Benennung von Spalten, bei denen es sich um Fremdschlüssel handelte.

Es ist wie mit Datenbanknormalisierung – Sie müssen wissen, was Sie tun und welche Konsequenzen das hat (hauptsächlich Leistung).

Ich bin mir der Vorteile von Fremdschlüsseln bewusst (Datenintegrität, Index für Fremdschlüsselspalten, Tools, die das Datenbankschema kennen), aber ich habe auch Angst davor, als allgemeine Regel Fremdschlüssel zu verwenden.

Außerdem könnten verschiedene Datenbank-Engines Fremdschlüssel auf unterschiedliche Weise bereitstellen, was zu subtilen Fehlern während der Migration führen könnte.

Das Entfernen aller Bestellungen und Rechnungen gelöschter Kunden mit ON DELETE CASCADE ist das perfekte Beispiel für ein gut aussehendes, aber falsch gestaltetes Datenbankschema.

Ja.Das ON DELETE [RESTRICT|CASCADE] verhindert, dass Entwickler Daten stranden und die Daten sauber bleiben.Ich bin kürzlich einem Team von Rails-Entwicklern beigetreten, die sich nicht auf Datenbankeinschränkungen wie Fremdschlüssel konzentriert haben.

Zum Glück habe ich diese gefunden: http://www.redhillonrails.org/foreign_key_associations.html – RedHill on Ruby on Rails-Plug-Ins generieren Fremdschlüssel mithilfe von Konvention über Konfiguration Stil.Eine Migration mit Produkt ID erstellt einen Fremdschlüssel für die Ausweis im Produkte Tisch.

Schauen Sie sich die anderen tollen Plug-Ins an Roter Hügel, einschließlich in Transaktionen verpackter Migrationen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top