Ich erinnere mich, wie Joel Spolsky im Podcast 014 erwähnte, dass er kaum jemals einen Fremdschlüssel verwendet hatte (wenn ich mich richtig erinnere). Für mich scheinen sie jedoch sehr wichtig zu sein, um Doppelarbeit und nachfolgende Datenintegritätsprobleme in Ihrer Datenbank zu vermeiden.

Haben die Leute gute Gründe, warum (um eine Diskussion im Einklang mit den Stack Overflow-Prinzipien zu vermeiden)?

Bearbeiten: "Ich habe noch keinen Grund, einen Fremdschlüssel zu erstellen. Dies könnte mein erster Grund sein, einen tatsächlich einzurichten."

Gründe für die Verwendung von Fremdschlüsseln:

• Sie werden keine verwaisten Zeilen erhalten
• Sie können ein nettes Verhalten beim Löschen von Kaskaden erzielen, indem Sie Tabellen automatisch bereinigen
• Wenn Sie die Beziehungen zwischen Tabellen in der Datenbank kennen, kann das Optimierungsprogramm Ihre Abfragen für eine möglichst effiziente Ausführung planen, da es bessere Schätzungen zur Join-Kardinalität erhalten kann.
• FKs geben einen ziemlich großen Hinweis darauf, welche Statistiken in der Datenbank am wichtigsten sind, was wiederum zu einer besseren Leistung führt
• Sie ermöglichen alle Arten von automatisch generierter Unterstützung - ORMs können sich selbst generieren, Visualisierungstools können schöne Schema-Layouts für Sie erstellen usw.
• Jemand, der neu im Projekt ist, wird schneller in den Fluss der Dinge geraten, da ansonsten implizite Beziehungen explizit dokumentiert werden

Gründe, keine Fremdschlüssel zu verwenden:

• Sie sorgen dafür, dass die Datenbank bei jeder CRUD- Operation zusätzlich funktioniert, da die FK-Konsistenz überprüft werden muss. Dies kann ein großer Kostenfaktor sein, wenn Sie viel Abwanderung haben
• Durch das Erzwingen von Beziehungen geben FKs eine Reihenfolge an, in der Sie Dinge hinzufügen / löschen müssen, was dazu führen kann, dass die DB sich weigert, das zu tun, was Sie wollen. (Zugegeben, in solchen Fällen versuchen Sie, eine verwaiste Zeile zu erstellen, und das ist normalerweise keine gute Sache.) Dies ist besonders schmerzhaft, wenn Sie große Stapelaktualisierungen durchführen und eine Tabelle vor der anderen laden, wobei die zweite Tabelle einen konsistenten Status erstellt (sollten Sie dies jedoch tun, wenn die Möglichkeit besteht, dass das zweite Laden fehlschlägt und Ihre Datenbank ist jetzt inkonsistent?).
• Manchmal wissen Sie vorher, dass Ihre Daten schmutzig werden. Sie akzeptieren das und möchten, dass die Datenbank es akzeptiert
• du bist nur faul :-)

Ich denke (ich bin nicht sicher!), Dass die meisten etablierten Datenbanken eine Möglichkeit bieten, einen Fremdschlüssel anzugeben, der nicht erzwungen wird und nur ein bisschen Metadaten sind. Da die Nichtdurchsetzung jeden Grund auslöscht, FKs nicht zu verwenden, sollten Sie diesen Weg wahrscheinlich gehen, wenn einer der Gründe im zweiten Abschnitt zutrifft.

Dies ist eine Frage der Erziehung. Wenn Sie irgendwo in Ihrer Bildungs- oder Berufskarriere Zeit damit verbracht haben, Datenbanken zu füttern und zu pflegen (oder eng mit talentierten Leuten zusammengearbeitet haben), dann sind die grundlegenden Grundsätze von Entitäten und Beziehungen in Ihrem Denkprozess gut verankert. Zu diesen Grundlagen gehört, wie / wann / warum Schlüssel in Ihrer Datenbank angegeben werden sollen (primär, fremd und möglicherweise alternativ). Es ist eine zweite Natur.

Wenn Sie jedoch in Ihrer Vergangenheit keine so gründlichen oder positiven Erfahrungen mit RDBMS-bezogenen Bemühungen gemacht haben, waren Sie wahrscheinlich keinen solchen Informationen ausgesetzt. Oder vielleicht beinhaltet Ihre Vergangenheit das Eintauchen in eine Umgebung, die lautstark gegen die Datenbank war (z. B. "Diese Datenbankadministratoren sind Idioten - wir wenige, wir haben nur wenige Java / C # -Code-Slinger ausgewählt, die den Tag retten"). In diesem Fall könnten Sie vehement dagegen sein zu den arkanen Plappern einiger Dweeb, die Ihnen sagen, dass FKs (und die Einschränkungen, die sie implizieren können) wirklich wichtig sind, wenn Sie nur zuhören.

Fast allen wurde als Kind beigebracht, dass das Zähneputzen wichtig ist. Kannst du ohne auskommen? Sicher, aber irgendwo auf der ganzen Linie stehen Ihnen weniger Zähne zur Verfügung, als wenn Sie nach jeder Mahlzeit geputzt hätten. Wenn Mütter und Väter verantwortlich genug wären, um das Datenbankdesign sowie die Mundhygiene abzudecken, würden wir dieses Gespräch nicht führen. :-)

Ich bin mir sicher, dass es viele Anwendungen gibt, mit denen Sie davonkommen können, aber es ist nicht die beste Idee. Sie können sich nicht immer darauf verlassen, dass Ihre Anwendung Ihre Datenbank ordnungsgemäß verwaltet, und ehrlich gesagt sollte die Verwaltung der Datenbank für Ihre Anwendung kein großes Problem darstellen.

Wenn Sie eine relationale Datenbank verwenden, sollten in dieser Beziehung einige Beziehungen definiert sein. Leider scheint diese Einstellung (Sie benötigen keine Fremdschlüssel) von vielen Anwendungsentwicklern angenommen zu werden, die sich lieber nicht mit albernen Dingen wie Datenintegrität beschäftigen möchten (aber müssen, weil ihre Unternehmen keine dedizierten Datenbankentwickler haben). Normalerweise haben Sie in Datenbanken, die nach diesen Typen zusammengestellt wurden, das Glück, nur Primärschlüssel zu haben;)

Fremdschlüssel sind für jedes relationale Datenbankmodell unerlässlich .

Ich benutze sie immer, aber dann mache ich Datenbanken für Finanzsysteme. Die Datenbank ist der kritische Teil der Anwendung. Wenn die Daten in einer Finanzdatenbank nicht vollständig korrekt sind, spielt es keine Rolle, wie viel Aufwand Sie in Ihr Code- / Front-End-Design investieren. Du verschwendest nur deine Zeit.

Es gibt auch die Tatsache, dass mehrere Systeme im Allgemeinen direkt mit der Datenbank verbunden werden müssen - von anderen Systemen, die nur Daten auslesen (Crystal Reports), bis zu Systemen, die Daten einfügen (nicht unbedingt unter Verwendung einer von mir entworfenen API; es kann von einem geschrieben werden langweiliger Manager, der gerade VBScript entdeckt hat und das SA-Passwort für die SQL-Box hat). Wenn die Datenbank nicht so idiotensicher ist, wie es nur sein kann, tschüss Datenbank.

Wenn Ihre Daten wichtig sind, verwenden Sie Fremdschlüssel, erstellen Sie eine Reihe gespeicherter Prozeduren, um mit den Daten zu interagieren, und erstellen Sie die härteste Datenbank, die Sie können. Wenn Ihre Daten nicht wichtig sind, warum erstellen Sie zunächst eine Datenbank?

Update : Ich benutze jetzt immer Fremdschlüssel. Meine Antwort auf den Einwand "Sie haben das Testen kompliziert" lautet "Schreiben Sie Ihre Komponententests, damit sie die Datenbank überhaupt nicht benötigen. Alle Tests, die die Datenbank verwenden, sollten sie ordnungsgemäß verwenden und Fremdschlüssel enthalten. Wenn das Setup schmerzhaft ist, finde einen weniger schmerzhaften Weg, um das Setup durchzuführen. "

Fremdschlüssel erschweren das automatisierte Testen

Angenommen, Sie verwenden Fremdschlüssel. Sie schreiben einen automatisierten Test, der besagt: "Wenn ich ein Finanzkonto aktualisiere, sollte es eine Aufzeichnung der Transaktion speichern." In diesem Test geht es nur um zwei Tabellen: accountsund transactions.

Allerdings accountshat einen Fremdschlüssel contracts, und contractshat eine fk clientsund clientshat eine fk citiesund citieshat eine fk states.

In der Datenbank können Sie Ihren Test jetzt nicht mehr ausführen, ohne Daten in vier Tabellen einzurichten, die nicht mit Ihrem Test zusammenhängen .

Hierfür gibt es mindestens zwei mögliche Perspektiven:

• "Das ist eine gute Sache: Ihr Test sollte realistisch sein, und diese Datenbeschränkungen werden in der Produktion bestehen."
• "Das ist eine schlechte Sache: Sie sollten in der Lage sein, Testteile des Systems zu vereinheitlichen, ohne andere Teile einzubeziehen. Sie können Integrationstests für das gesamte System hinzufügen."

Es kann auch möglich sein, Fremdschlüsselprüfungen vorübergehend auszuschalten, während Tests ausgeführt werden. Zumindest MySQL unterstützt dies .

"Sie können das Löschen von Datensätzen umständlicher machen. Sie können den" Master "-Datensatz nicht löschen, wenn Datensätze in anderen Tabellen vorhanden sind, in denen Fremdschlüssel gegen diese Einschränkung verstoßen würden."

Es ist wichtig zu beachten, dass der SQL-Standard Aktionen definiert, die ausgeführt werden, wenn ein Fremdschlüssel gelöscht oder aktualisiert wird. Diejenigen, die ich kenne, sind:

• ON DELETE RESTRICT- Verhindert, dass Zeilen in der anderen Tabelle mit Schlüsseln in dieser Spalte gelöscht werden. Dies ist, was Ken Ray oben beschrieben hat.
• ON DELETE CASCADE - Wenn eine Zeile in der anderen Tabelle gelöscht wird, löschen Sie alle Zeilen in dieser Tabelle, die darauf verweisen.
• ON DELETE SET DEFAULT - Wenn eine Zeile in der anderen Tabelle gelöscht wird, setzen Sie alle Fremdschlüssel, die darauf verweisen, auf die Standardeinstellung der Spalte.
• ON DELETE SET NULL - Wenn eine Zeile in der anderen Tabelle gelöscht wird, setzen Sie alle Fremdschlüssel, die in dieser Tabelle darauf verweisen, auf null.
• ON DELETE NO ACTION- Dieser Fremdschlüssel kennzeichnet nur, dass es sich um einen Fremdschlüssel handelt. nämlich zur Verwendung in OP-Mappern.

Dieselben Aktionen gelten auch für ON UPDATE.

Die Standardeinstellung scheint davon abzuhängen sql Server, den Sie verwenden.

@imphasing - Dies ist genau die Art von Denkweise, die Wartungs-Albträume verursacht.

Warum, warum sollten Sie die deklarative referenzielle Integrität ignorieren, bei der garantiert werden kann, dass die Daten zumindest konsistent sind, zugunsten der sogenannten "Software-Durchsetzung", die bestenfalls eine schwache vorbeugende Maßnahme darstellt?

Es gibt einen guten Grund, sie nicht zu verwenden: Wenn Sie ihre Rolle oder ihre Verwendung nicht verstehen.

In den falschen Situationen können Fremdschlüsseleinschränkungen zur Replikation von Unfällen durch Wasserfälle führen. Wenn jemand den falschen Datensatz entfernt, kann das Rückgängigmachen zu einer Mammutaufgabe werden.

Umgekehrt können Einschränkungen, wenn Sie etwas entfernen müssen, wenn sie schlecht entworfen sind, alle Arten von Sperren verursachen, die Sie verhindern.

Es gibt keine guten Gründe, sie nicht zu verwenden ... es sei denn, verwaiste Zeilen sind für Sie keine große Sache, denke ich.

Die größere Frage ist: Würden Sie mit verbundenen Augen fahren? So ist es, wenn Sie ein System ohne referenzielle Einschränkungen entwickeln. Beachten Sie, dass sich die Geschäftsanforderungen ändern, sich das Anwendungsdesign ändert, die jeweiligen logischen Annahmen in den Codeänderungen, die Logik selbst überarbeitet werden kann und so weiter. Im Allgemeinen werden Einschränkungen in Datenbanken unter zeitgemäßen logischen Annahmen festgelegt, die für bestimmte logische Aussagen und Annahmen scheinbar korrekt sind.

Während des Lebenszyklus einer Anwendung schränken Referenz- und Datenprüfungen die Erfassung von Polizeidaten über die Anwendung ein, insbesondere wenn neue Anforderungen zu logischen Anwendungsänderungen führen.

Zum Thema dieser Auflistung : Ein Fremdschlüssel "verbessert" weder die Leistung selbst noch "verschlechtert er die Leistung" unter dem Gesichtspunkt eines Echtzeit-Transaktionsverarbeitungssystems erheblich. Es gibt jedoch aggregierte Kosten für die Einschränkungsprüfung im "Batch" -System mit hohem Volumen. Hier ist also der Unterschied zwischen Echtzeit- und Batch-Transaktionsprozess. Stapelverarbeitung - Wenn die hohen Kosten einer sequentiell verarbeiteten Charge, die durch Einschränkungsprüfungen entstehen, einen Leistungseinbruch darstellen.

In einem gut konzipierten System würden Datenkonsistenzprüfungen "vor" der Verarbeitung eines Stapels durchgeführt (dennoch sind auch hier Kosten verbunden). Daher sind während der Ladezeit keine Fremdschlüsseleinschränkungsprüfungen erforderlich. Tatsächlich sollten alle Einschränkungen, einschließlich des Fremdschlüssels, vorübergehend deaktiviert werden, bis der Stapel verarbeitet wird.

QUERY PERFORMANCE - Wenn Tabellen mit Fremdschlüsseln verknüpft werden, beachten Sie, dass Fremdschlüsselspalten NICHT INDEXIERT sind (obwohl der jeweilige Primärschlüssel per Definition indiziert ist). Durch Indizieren eines Fremdschlüssels, Indizieren eines beliebigen Schlüssels und Verknüpfen von Tabellen mit indizierten Schlüsseln wird eine bessere Leistung erzielt, nicht durch Verbinden mit nicht indizierten Schlüsseln mit Fremdschlüsseleinschränkung.

Ändern von Themen , wenn eine Datenbank nur das Anzeigen / Rendern von Inhalten / usw. auf der Website und das Aufzeichnen von Klicks unterstützt, ist eine Datenbank mit vollständigen Einschränkungen für alle Tabellen für solche Zwecke überfordert. Denk darüber nach. Die meisten Websites verwenden nicht einmal eine Datenbank für solche. Verwenden Sie für ähnliche Anforderungen, bei denen Daten nur aufgezeichnet und nicht per Referenz referenziert werden, eine speicherinterne Datenbank, für die keine Einschränkungen gelten. Dies bedeutet nicht, dass es kein Datenmodell, ja ein logisches Modell, aber kein physisches Datenmodell gibt.

Zusätzlicher Grund für die Verwendung von Fremdschlüsseln: - Ermöglicht eine stärkere Wiederverwendung einer Datenbank

Zusätzlicher Grund, KEINE Fremdschlüssel zu verwenden: - Sie versuchen, einen Kunden an Ihr Tool zu binden, indem Sie die Wiederverwendung reduzieren.

Aus meiner Erfahrung ist es immer besser, die Verwendung von FKs in datenbankkritischen Anwendungen zu vermeiden. Ich würde den Leuten hier nicht widersprechen, die sagen, dass FKs eine gute Praxis sind, aber es ist nicht praktisch, wenn die Datenbank riesig ist und riesige CRUD-Operationen / Sek. Hat. Ich kann teilen, ohne zu nennen ... eine der größten Investmentbanken von hat keine einzige FK in Datenbanken. Diese Einschränkungen werden von Programmierern beim Erstellen von Anwendungen mit DB behandelt. Der Hauptgrund ist, dass jedes Mal, wenn eine neue CRUD erstellt wird, mehrere Tabellen erstellt und für jedes Einfügen / Aktualisieren überprüft werden müssen. Dies ist jedoch kein großes Problem für Abfragen, die einzelne Zeilen betreffen, führt jedoch zu einer enormen Latenz, wenn Sie sich damit befassen Stapelverarbeitung, die jede Großbank als tägliche Aufgabe erledigen muss.

Es ist besser, FKs zu vermeiden, aber das Risiko muss von Programmierern gehandhabt werden.

"Überprüfen Sie vor dem Hinzufügen eines Datensatzes, ob ein entsprechender Datensatz in einer anderen Tabelle vorhanden ist", lautet die Geschäftslogik.

Hier sind einige Gründe, warum Sie dies nicht in der Datenbank haben möchten:

1. Wenn sich die Geschäftsregeln ändern, müssen Sie die Datenbank ändern. In vielen Fällen muss die Datenbank den Index neu erstellen. Dies ist bei großen Tabellen langsam. (Zu den sich ändernden Regeln gehören: Gäste können Nachrichten posten oder Benutzer können ihr Konto löschen, obwohl sie Kommentare usw. gepostet haben.)

2. Das Ändern der Datenbank ist nicht so einfach wie das Bereitstellen eines Software-Fixes, indem die Änderungen in das Produktions-Repository übertragen werden. Wir möchten vermeiden, die Datenbankstruktur so weit wie möglich zu ändern. Je mehr Geschäftslogik in der Datenbank vorhanden ist, desto größer ist die Wahrscheinlichkeit, dass die Daten geändert werden müssen (und eine Neuindizierung ausgelöst wird).

3. TDD. In Unit-Tests können Sie die Datenbank durch Mocks ersetzen und die Funktionalität testen. Wenn Ihre Datenbank eine Geschäftslogik enthält, führen Sie keine vollständigen Tests durch und müssen zu Testzwecken entweder mit der Datenbank testen oder die Geschäftslogik im Code replizieren, die Logik duplizieren und die Wahrscheinlichkeit erhöhen, dass die Logik in der Datenbank nicht funktioniert gleicher Weg.

4. Wiederverwendung Ihrer Logik mit verschiedenen Datenquellen. Wenn die Datenbank keine Logik enthält, kann meine Anwendung Objekte aus Datensätzen aus der Datenbank erstellen, sie aus einem Webdienst, einer JSON-Datei oder einer anderen Quelle erstellen. Ich muss nur die Data Mapper-Implementierung austauschen und kann meine gesamte Geschäftslogik mit jeder Quelle verwenden. Wenn die Datenbank Logik enthält, ist dies nicht möglich, und Sie müssen die Logik auf der Data Mapper-Ebene oder in der Geschäftslogik implementieren. In jedem Fall benötigen Sie diese Überprüfungen in Ihrem Code. Wenn die Datenbank keine Logik enthält, kann ich die Anwendung mithilfe verschiedener Datenbank- oder Flatfile-Implementierungen an verschiedenen Speicherorten bereitstellen.

Ich stimme den vorherigen Antworten darin zu, dass sie nützlich sind, um die Datenkonsistenz aufrechtzuerhalten. Vor einigen Wochen gab es jedoch einen interessanten Beitrag von Jeff Atwood , in dem die Vor- und Nachteile normalisierter und konsistenter Daten erörtert wurden.

Mit wenigen Worten, eine denormalisierte Datenbank kann schneller sein, wenn große Datenmengen verarbeitet werden. Je nach Anwendung ist Ihnen die genaue Konsistenz möglicherweise nicht wichtig, aber Sie müssen beim Umgang mit Daten viel vorsichtiger sein, da dies bei der Datenbank nicht der Fall ist.

Die Clarify-Datenbank ist ein Beispiel für eine kommerzielle Datenbank ohne Primär- oder Fremdschlüssel.

http://www.geekinterview.com/question_details/18869

Das Lustige ist, dass die technische Dokumentation sehr ausführlich erklärt, wie Tabellen zusammenhängen, welche Spalten zum Verknüpfen verwendet werden müssen usw.

Mit anderen Worten, sie könnten die Tabellen mit expliziten Erklärungen beigetreten sind (DRI) , aber sie wählten nicht .

Folglich ist die Clarify-Datenbank voller Inkonsistenzen und weist eine Underperformance auf.

Aber ich nehme an, es hat den Entwicklern die Arbeit erleichtert, da sie keinen Code schreiben müssen, um die referenzielle Integrität zu gewährleisten, z. B. vor dem Löschen und Hinzufügen nach verwandten Zeilen zu suchen.

Und das ist meiner Meinung nach der Hauptvorteil, wenn in einer relationalen Datenbank keine Fremdschlüsseleinschränkungen vorhanden sind. Es macht es einfacher, sich zu entwickeln, zumindest aus der Sicht des Teufels.

Ich kenne nur Oracle-Datenbanken, keine anderen, und ich kann sagen, dass Fremdschlüssel für die Aufrechterhaltung der Datenintegrität unerlässlich sind. Vor dem Einfügen von Daten muss eine Datenstruktur erstellt und korrekt erstellt werden. Wenn das erledigt ist - und somit alle Primär- UND Fremdschlüssel erstellt sind - ist die Arbeit erledigt!

Bedeutung: verwaiste Reihen? Ich habe das noch nie in meinem Leben gesehen. Es sei denn, ein schlechter Programmierer hat den Fremdschlüssel vergessen oder er hat ihn auf einer anderen Ebene implementiert. Beides sind - im Kontext von Oracle - große Fehler, die zu Datenverdoppelung, verwaisten Daten und damit zu Datenkorruption führen. Ich kann mir keine Datenbank ohne FK vorstellen. Es sieht für mich nach Chaos aus. Es ist ein bisschen wie beim Unix-Berechtigungssystem: Stellen Sie sich vor, jeder ist root. Denken Sie an das Chaos.

Fremdschlüssel sind ebenso wichtig wie Primärschlüssel. Es ist wie zu sagen: Was ist, wenn wir Primärschlüssel entfernen? Nun, es wird totales Chaos passieren. Das ist, was. Sie dürfen die Primär- oder Fremdschlüsselverantwortung nicht auf die Programmierebene verschieben, sie muss sich auf Datenebene befinden.

Nachteile? Ja absolut ! Denn beim Einfügen werden viel mehr Überprüfungen stattfinden. Wenn Datenintegrität jedoch wichtiger ist als Leistung, ist dies ein Kinderspiel. Das Problem mit der Leistung unter Oracle hängt eher mit Indizes zusammen, die mit PK und FKs geliefert werden.

Sie können das Löschen von Datensätzen umständlicher machen - Sie können den "Master" -Datensatz nicht löschen, wenn sich Datensätze in anderen Tabellen befinden, in denen Fremdschlüssel gegen diese Einschränkung verstoßen würden. Sie können Trigger verwenden, um kaskadierende Löschvorgänge durchzuführen.

Wenn Sie Ihren Primärschlüssel unklug gewählt haben, wird die Änderung dieses Werts noch komplexer. Wenn ich zum Beispiel die PK meiner "Kunden" -Tabelle als Namen der Person habe und diesen Schlüssel zu einer FK in der "Bestellungen" -Tabelle mache, wenn der Kunde seinen Namen ändern möchte, ist dies ein königlicher Schmerz. Aber das ist nur ein schlechtes Datenbankdesign.

Ich glaube, dass die Vorteile bei der Verwendung von Fireign-Schlüsseln die vermeintlichen Nachteile überwiegen.

Das Überprüfen von Fremdschlüsseleinschränkungen benötigt einige CPU-Zeit, sodass einige Benutzer Fremdschlüssel weglassen, um zusätzliche Leistung zu erzielen.

Ich habe dieses Argument auch gehört - von Leuten, die vergessen haben, einen Index für ihre Fremdschlüssel zu erstellen, und sich dann darüber beschwert haben, dass bestimmte Vorgänge langsam waren (weil die Einschränkungsprüfung jeden Index ausnutzen könnte). Fazit: Es gibt keinen guten Grund, keine Fremdschlüssel zu verwenden. Alle modernen Datenbanken unterstützen kaskadierte Löschvorgänge.

Das Argument, das ich gehört habe, ist, dass das Front-End diese Geschäftsregeln haben sollte. Fremdschlüssel "fügen unnötigen Overhead hinzu", wenn Sie keine Einfügungen zulassen sollten, die Ihre Einschränkungen in erster Linie verletzen. Bin ich damit einverstanden? Nein, aber das habe ich immer gehört.

EDIT: Ich vermute, er bezog sich auf Fremdschlüsseleinschränkungen , nicht auf Fremdschlüssel als Konzept.

Wenn Sie sich an die ACID- Standards halten möchten , ist es für mich wichtig, Fremdschlüssel zu haben, um die referenzielle Integrität sicherzustellen.

Ich muss die meisten Kommentare hier unterstützen. Fremdschlüssel sind notwendige Elemente, um sicherzustellen, dass Sie Daten mit Integrität haben. Mit den verschiedenen Optionen für ON DELETE und ON UPDATE können Sie einige der "Down Falls" umgehen, die hier in Bezug auf ihre Verwendung erwähnt werden.

Ich finde, dass ich in 99% aller meiner Projekte FKs haben werde, um die Integrität der Daten durchzusetzen. Es gibt jedoch seltene Fälle, in denen ich Kunden habe, die ihre alten Daten behalten MÜSSEN, unabhängig davon, wie schlecht sie sind. Aber dann verbringe ich viel Zeit damit, Code zu schreiben, der ohnehin nur die gültigen Daten abruft, sodass er sinnlos wird.

Wie wäre es mit Wartbarkeit und Konstanz über Anwendungslebenszyklen hinweg? Die meisten Daten haben eine längere Lebensdauer als die Anwendungen, die sie verwenden. Beziehungen und Datenintegrität sind viel zu wichtig, um der Hoffnung zu überlassen, dass das nächste Entwicklerteam sie im App-Code richtig macht. Wenn Sie nicht an einer Datenbank mit schmutzigen Daten gearbeitet haben, die die natürlichen Beziehungen nicht berücksichtigen, werden Sie dies tun. Die Bedeutung der Datenintegrität wird dann sehr deutlich.

Ich denke auch, dass Fremdschlüssel in den meisten Datenbanken eine Notwendigkeit sind. Der einzige Nachteil (neben dem Leistungseinbruch, der mit der erzwungenen Konsistenz einhergeht) besteht darin, dass mit einem Fremdschlüssel Code geschrieben werden kann, der davon ausgeht, dass es einen funktionierenden Fremdschlüssel gibt. Das sollte niemals erlaubt sein.

Ich habe zum Beispiel gesehen, wie Leute Code schreiben, der in die referenzierte Tabelle eingefügt wird, und dann versuchen, Einfügungen in die referenzierende Tabelle vorzunehmen, ohne zu überprüfen, ob die erste Einfügung erfolgreich war. Wenn der Fremdschlüssel zu einem späteren Zeitpunkt entfernt wird, führt dies zu einer inkonsistenten Datenbank.

Sie haben auch nicht die Möglichkeit, beim Aktualisieren oder Löschen ein bestimmtes Verhalten anzunehmen. Sie müssen Ihren Code noch schreiben, um das zu tun, was Sie wollen, unabhängig davon, ob ein Fremdschlüssel vorhanden ist. Wenn Sie davon ausgehen, dass Löschvorgänge kaskadiert sind, wenn dies nicht der Fall ist, schlagen Ihre Löschvorgänge fehl. Wenn Sie davon ausgehen, dass Aktualisierungen der referenzierten Spalten auf die referenzierenden Zeilen übertragen werden, wenn dies nicht der Fall ist, schlagen Ihre Aktualisierungen fehl. Zum Schreiben von Code verfügen Sie möglicherweise auch nicht über diese Funktionen.

Wenn diese Funktionen aktiviert sind, emuliert Ihr Code sie trotzdem und Sie verlieren ein wenig an Leistung.

Also, die Zusammenfassung ... Fremdschlüssel sind wichtig, wenn Sie eine konsistente Datenbank benötigen. Es sollte niemals angenommen werden, dass Fremdschlüssel in dem von Ihnen geschriebenen Code vorhanden oder funktionsfähig sind.

Ich stimme der Antwort von Dmitriy zu - sehr gut ausgedrückt.

Für diejenigen, die sich Sorgen über den Leistungsaufwand machen, den FK häufig mit sich bringt, gibt es eine Möglichkeit (in Oracle), den Vorteil des Abfrageoptimierers der FK-Einschränkung zu nutzen, ohne den Kostenaufwand für die Validierung von Einschränkungen beim Einfügen, Löschen oder Aktualisieren. Das heißt, Sie erstellen die FK-Einschränkung mit den Attributen RELY DISABLE NOVALIDATE. Dies bedeutet, dass der Abfrageoptimierer davon ausgeht, dass die Einschränkung beim Erstellen von Abfragen erzwungen wurde, ohne dass die Datenbank die Einschränkung tatsächlich erzwingt. Sie müssen hier sehr vorsichtig sein, um die Verantwortung zu übernehmen, wenn Sie eine Tabelle mit einer solchen FK-Einschränkung füllen, um sicherzustellen, dass Ihre FK-Spalte (n) keine Daten enthält, die gegen die Einschränkung verstoßen, als ob Sie dies tun Es kann zu unzuverlässigen Ergebnissen bei Abfragen kommen, die die Tabelle betreffen, für die diese FK-Einschränkung gilt.

Normalerweise verwende ich diese Strategie für einige Tabellen in meinem Data Mart-Schema, jedoch nicht in meinem integrierten Staging-Schema. Ich stelle sicher, dass für die Tabellen, aus denen ich Daten kopiere, bereits dieselbe Einschränkung erzwungen wurde, oder dass die ETL-Routine die Einschränkung erzwingt.

Viele der hier antwortenden Personen sind zu sehr von der Bedeutung der referenziellen Integrität abhängig, die über referenzielle Einschränkungen implementiert wird. Die Arbeit an großen Datenbanken mit referenzieller Integrität funktioniert einfach nicht gut. Oracle scheint besonders schlecht darin zu sein, Löschvorgänge zu kaskadieren. Meine Faustregel lautet, dass Anwendungen die Datenbank niemals direkt aktualisieren sollten und über eine gespeicherte Prozedur erfolgen sollten. Dadurch bleibt die Codebasis in der Datenbank erhalten, und die Datenbank behält ihre Integrität bei.

Wenn viele Anwendungen möglicherweise auf die Datenbank zugreifen, treten Probleme aufgrund von Einschränkungen der referenziellen Integrität auf, dies liegt jedoch an einem Steuerelement.

Es gibt auch ein größeres Problem darin, dass Anwendungsentwickler möglicherweise sehr unterschiedliche Anforderungen haben, mit denen Datenbankentwickler möglicherweise nicht unbedingt so vertraut sind.

Wenn Sie absolut sicher sind, dass sich das zugrunde liegende Datenbanksystem in Zukunft nicht ändern wird, würde ich Fremdschlüssel verwenden, um die Datenintegrität sicherzustellen.

Aber hier ist ein weiterer sehr guter Grund im wirklichen Leben, überhaupt keine Fremdschlüssel zu verwenden:

Sie entwickeln ein Produkt, das verschiedene Datenbanksysteme unterstützen soll.

Wenn Sie mit dem Entity Framework arbeiten, das eine Verbindung zu vielen verschiedenen Datenbanksystemen herstellen kann, möchten Sie möglicherweise auch serverlose Open-Source-Datenbanken unterstützen. Möglicherweise unterstützen nicht alle diese Datenbanken Ihre Fremdschlüsselregeln (Aktualisieren, Löschen von Zeilen ...).

Dies kann zu unterschiedlichen Problemen führen:

1.) Beim Erstellen oder Aktualisieren der Datenbankstruktur können Fehler auftreten. Möglicherweise treten nur stille Fehler auf, da Ihre Fremdschlüssel vom Datenbanksystem einfach ignoriert werden.

2.) Wenn Sie sich auf Fremdschlüssel verlassen, werden Sie wahrscheinlich weniger oder gar keine Datenintegritätsprüfungen in Ihrer Geschäftslogik durchführen. Wenn das neue Datenbanksystem diese Fremdschlüsselregeln nicht unterstützt oder sich nur anders verhält, müssen Sie Ihre Geschäftslogik neu schreiben.

Sie fragen sich vielleicht: Wer braucht unterschiedliche Datenbanksysteme? Nun, nicht jeder kann oder will sich einen vollwertigen SQL-Server auf seinem Computer leisten. Dies ist Software, die gewartet werden muss. Andere haben bereits Zeit und Geld in ein anderes DB-System investiert. Serverlose Datenbanken eignen sich hervorragend für kleine Kunden auf nur einem Computer.

Niemand weiß, wie sich all diese DB-Systeme verhalten, aber Ihre Geschäftslogik mit Integritätsprüfungen bleibt immer gleich.

Ich fand es immer faul, sie nicht zu benutzen. Mir wurde beigebracht, dass es immer getan werden sollte. Aber dann habe ich Joels Diskussion nicht gehört. Er hat vielleicht einen guten Grund gehabt, ich weiß es nicht.

Ein FK kann zu Problemen führen, wenn Sie über historische Daten verfügen, die auf den Schlüssel verweisen (in einer Nachschlagetabelle), obwohl der Schlüssel nicht mehr verfügbar sein soll.
Natürlich besteht die Lösung darin, die Dinge im Vorfeld besser zu gestalten, aber ich denke an Situationen in der realen Welt, in denen Sie nicht immer die Kontrolle über die vollständige Lösung haben.
Beispiel: Vielleicht haben Sie eine Nachschlagetabelle customer_type, in der verschiedene Kundentypen aufgelistet sind. Nehmen wir an, Sie müssen einen bestimmten Kundentyp entfernen, können jedoch (aus geschäftlichen Gründen) die Client-Software nicht aktualisieren, und niemand hat diese Situation verletzt Bei der Entwicklung der Software kann die Tatsache, dass es sich um einen Fremdschlüssel in einer anderen Tabelle handelt, verhindern, dass Sie die Zeile entfernen, obwohl Sie die historischen Daten kennen, die darauf verweisen, ist irrelevant.
Nachdem Sie ein paar Mal damit verbrannt wurden, lehnen Sie sich wahrscheinlich von der Durchsetzung von Beziehungen durch die Datenbank ab.
(Ich sage nicht, dass dies gut ist - geben Sie nur einen Grund an, warum Sie sich entscheiden könnten, FKs und DB-Einschränkungen im Allgemeinen zu vermeiden.)