Detaillierte Erklärung, ob die MySQL-Datenbank Fremdschlüsseleinschränkungen verwenden soll

1. Einleitung

Das Thema, ob Fremdschlüsseleinschränkungen verwendet werden sollen, ist bereits ein Klischee. In der Schule lehren uns unsere Lehrer hauptsächlich, Fremdschlüsseleinschränkungen festzulegen. In der Praxis verwenden wir jedoch häufig keine Fremdschlüssel, sondern steuern sie über die Codelogik. In den JAVA-Spezifikationen von Alibaba ist außerdem Folgendes klar festgelegt: [Obligatorisch] Fremdschlüssel und Kaskaden dürfen nicht verwendet werden und alle Fremdschlüsselkonzepte müssen auf der Anwendungsebene aufgelöst werden.

Warum müssen wir solche Regelungen treffen? Sollten Fremdschlüsseleinschränkungen verwendet werden? Wir können zur Veranschaulichung ein Beispiel geben

2. Beispiele

Jetzt haben wir zwei Tabellen in der Datenbank erstellt: [Produkt und Projekt]. Das porduct von [Projekt] ist mit Product verknüpft. Zwischen ihnen befindet sich ein Fremdschlüsseldatensatz, wie in der folgenden Abbildung dargestellt:

Wenn wir der Tabelle [Projekt] einen Datensatz mit der project_id 1 hinzufügen, wird ein Fehler gemeldet, da in der Tabelle [Produkt] kein entsprechender Datensatz vorhanden ist:

Es ist ersichtlich, dass die Existenz dieser Einschränkung die Integrität der Beziehung zwischen den Daten in den Tabellen sicherstellt. Die Wahrscheinlichkeit, dass fehlerhafte Daten vorhanden sind, ist geringer. Dies ist ein ganz offensichtlicher Vorteil von Fremdschlüsseleinschränkungen!

Zusammenfassend bieten Fremdschlüsseleinschränkungen die folgenden Vorteile:

• Gewährleistung der Datenintegrität und -konsistenz
• Komfortabler Kaskadenbetrieb
• Die Beurteilung der Datenintegrität wird der Datenbank anvertraut, wodurch die Menge an Programmcode reduziert wird

Es gibt aber auch Nachteile, die nicht außer Acht gelassen werden können:

Leistungsprobleme

Wir haben gerade zwei Tabellen erstellt, [Projekt] und [Produkt]. Die Tabelle [Projekt] hat über das Feld project_id eine Fremdschlüsseleinschränkung mit der Tabelle [Produkt].

Zu diesem Zeitpunkt wird jedes Mal, wenn wir Daten in die Tabelle [Projekt] einfügen, zuerst zu [Produkt] gegangen, um zu prüfen, ob entsprechende zugehörige Daten vorhanden sind. Wenn dies vom Programm gesteuert wird, kann diese Abfrage weggelassen werden. Wenn jedoch eine Fremdschlüsseleinschränkung eingerichtet ist, wird die Abfrage auf jeden Fall ausgeführt. Das ist eigentlich überflüssig. Wenn nur wenige verknüpfte Felder vorhanden sind, treten möglicherweise keine Auswirkungen auf. Sobald jedoch mehr verknüpfte Felder vorhanden sind, sind diese Auswirkungen besonders deutlich!

Deadlock

Fremdschlüssel führen dazu, dass Abfragen von anderen Tabellen abhängig sind, was bedeutet, dass InnoDB nach entsprechenden Werten in der übergeordneten Tabelle (oder verwandten Tabellen) suchen muss. Dadurch wird auch die Zeile in der übergeordneten Tabelle gesperrt, um sicherzustellen, dass die Zeile nicht gelöscht wird, bevor die Transaktion abgeschlossen ist. Dies kann zu unerwarteten Wartezeiten bei Sperren oder sogar zu Deadlocks führen, die schwer zu lokalisieren sind.

Schwierigkeiten beim Sharding

Eine Datenbank mit Einschränkungen ist besonders schwierig zu verwenden, wenn sie in verschiedene Datenbanken und Tabellen aufgeteilt werden muss.

Reduzierte Entwicklungs-/Testeffizienz

In unserem täglichen Testprozess stoßen wir häufig auf Situationen, in denen wir einen Fehler finden und ihn reproduzieren oder das Testen vereinfachen möchten. Um das Testen zu vereinfachen, ändern wir die Daten in der Datenbanktabelle direkt.

Obwohl dies nicht standardisiert ist, kann es unsere Effizienz tatsächlich erheblich steigern. Das steht außer Zweifel! Allerdings können derartige Vorgänge auch Probleme mit sich bringen. Beispielsweise können durch Daten verursachte Fehler auftreten, bei denen es sich eigentlich nicht um Programmfehler handelt, oder potenzielle Fehler können nicht erkannt werden.

Abschluss

Derzeit verlangen viele, insbesondere große Internetunternehmen, die Deaktivierung von Fremdschlüsseln. Dies liegt nicht nur an Leistungsproblemen, sondern vor allem daran, dass sich das Internetgeschäft schnell ändert, was indirekt zu Änderungen in der Tabellenstruktur führt. Es ist sehr wahrscheinlich, dass das Vorhandensein von Fremdschlüsseleinschränkungen zu unerwarteten Problemen und einer verringerten Entwicklungseffizienz führt. Daher ist es nicht empfehlenswert, Fremdschlüsseleinschränkungen in nicht unbedingt notwendigen Situationen und Geschäftsszenarien zu verwenden, die keine hohe Zuverlässigkeit erfordern, um offener für Änderungen zu sein.
Aber wir können es nicht einfach abtun, weil manche Geschäftsszenarien besser durch die Verwendung von Fremdschlüsseleinschränkungen bedient werden, wie etwa Regierungsangelegenheiten, Bankwesen, Rüstungsindustrie usw., die eine hohe Datenzuverlässigkeit erfordern. Mein Vorschlag lautet daher: Wenn das Geschäft relativ komplex ist, können Sie in der Testumgebung Fremdschlüsseleinschränkungen verwenden, diese müssen in der Produktionsumgebung jedoch entfernt werden. Wenn das Geschäft relativ einfach ist, können Sie die Fremdschlüsseleinschränkung vollständig löschen. Für Szenarien wie das Bank- und Militärwesen, in denen keine Datenfehler zulässig sind und eine hohe Zuverlässigkeit erforderlich ist, wird jedoch die Festlegung von Fremdschlüsseleinschränkungen empfohlen.

Damit ist dieser Artikel darüber, ob MySQL-Datenbanken Fremdschlüsseleinschränkungen verwenden sollten, abgeschlossen. Weitere Informationen zu Fremdschlüsseleinschränkungen für MySQL-Datenbanken finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!