Wenn, wie in Ihrem Beitrag angegeben, eine relationale Datenbank (der Kürze halber RDB) erstellt werden soll und daher erwartet wird, dass sie als solche funktioniert, lautet die kurze Antwort:
- Nein, Sie sollten die Einschränkungen der Datenintegrität nicht übersehen .
Das Hauptziel sollte darin bestehen, die relevanten Daten so zu verwalten, wie sie sind, ein sehr wertvolles organisatorisches Gut, und eine zuverlässige Methode zur Erreichung dieses Ziels besteht darin, technische Mittel einzusetzen, die auf einer soliden Theorie beruhen.
Als Datenbankprofis können Sie daher die von Dr. EF Codd bereitgestellten hochmodernen und eleganten relationalen Modellmechanismen nutzen , um Geschäftsregeln durchzusetzen und Probleme zu vermeiden, die möglicherweise auftreten würden, wenn sie nicht verwendet werden.
In dieser Hinsicht werde ich (a) meine allgemeine Einstellung zu Einschränkungen und (b) einige Überlegungen zum Stand der Dinge in der Datenbank und zum fraglichen Arbeitsumfeld wie folgt teilen.
FOREIGN KEY-Einschränkungen, Datenbeziehungen und referenzielle Integrität
Ein RDB muss die Merkmale des interessierenden Geschäftskontexts mit hoher Genauigkeit widerspiegeln. Dies erfordert auf jeden Fall eine eingehende Analyse auf konzeptioneller Ebene , die von einem Modellierer oder Designer durchgeführt wird, der Best Practices befolgt und mit der unverzichtbaren Unterstützung der Geschäftsexperten zählt. Diese Analyse muss die korrekte Identifizierung und Formulierung der geltenden Geschäftsregeln ergeben .
Wenn ein solcher Modellierer festgestellt hat, dass Wechselbeziehungen zwischen den relevanten Daten bestehen, muss er die entsprechenden Einschränkungen auf logischer Ebene konfigurieren , damit das Datenbankverwaltungssystem (DBMS) sicherstellen kann, dass die Daten mit den genauen Merkmalen und übereinstimmen Regeln, die in der oben genannten Analyse festgelegt wurden, jederzeit .
In Bezug auf die zur Diskussion stehende Datenbank kann man schließen, dass die relevanten Wechselbeziehungen identifiziert wurden, da Sie erwähnen, dass es einen prozeduralen (und leicht zu umgehenden) Versuch gibt, sie von außerhalb der DBMS-Einrichtungen durch den Code des Anwendungsprogramms (welche) durchzusetzen ist ein vorrelationaler Ansatz), der in jedem Fall die Datenbank „berühren“ muss, um zu versuchen, die Ganzheitlichkeit dieser Wechselbeziehungen zu validieren.
Wie Sie wissen, ist dies jedoch nicht die optimale Technik zum Schutz der referenziellen Integrität , da die relationale Wissenschaft zu diesem Zweck ein sehr leistungsfähiges Instrument vorgeschrieben hat, dh FOREIGN KEY (FK) -Einschränkungen. Diese Einschränkungen sind sehr einfach zu erstellen (über den überlegenen deklarativen Ansatz), da es sich um einzelne Sätze handelt , die vermeiden, auf unnötige und fehleranfällige Ad-hoc-Verfahren zurückzugreifen. Es ist sehr nützlich zu bemerken, dass die Ausführungsgeschwindigkeit von FK-Einschränkungen von spezialisierten Programmierern stark optimiert wurde (und die großen Plattformanbieter bereits seit Jahrzehnten daran arbeiten).
Da eine RDB eine unabhängige (selbstschützende, selbstbeschreibende usw.) Softwarekomponente sein muss, auf die mehrere Anwendungsprogramme (Desktop, Automatisch, Web, Mobil, Kombinationen davon) zugreifen können, sollte dies nicht der Fall sein Mit dem Code einer dieser Apps „gekoppelt“.
Ebenso überleben die Daten - da sie eine bedeutende organisatorische Ressource darstellen - natürlich Anwendungsprogramme, Anwendungsprogrammierer, Anwendungsentwicklungsplattformen und Programmierparadigmen.
PRIMARY KEY-Einschränkungen und Auswirkungen doppelter Zeilen
Wenn - konzeptionell gesehen - eine bestimmte Art von Dingen in einem Geschäftsumfeld als wichtig erachtet wurde, muss ein Datenbankmodellierer (1) seine relevanten Merkmale - dh seine Eigenschaften - bestimmen und diese Art von Dingen als Prototyp einer Entitätsinstanz bestätigen - dh ein Entitätstyp - und (2) stellen ihn durch eine Tabelle dar , die durch eine oder mehrere Spalten in einem logischen Entwurf integriert ist.
Genau wie es für die Unterscheidung jeder einzelnen Instanz eines bestimmten Entitätstyps in der realen Welt von größter Bedeutung ist , muss auch jede in einer Tabelle enthaltene Zeile eindeutig unterschieden werden. Wenn für eine Tabelle kein KEY deklariert ist, werden möglicherweise Duplikate beibehalten. Wenn zwei oder mehr Zeilen genau dieselben Werte enthalten, haben alle dieselbe Bedeutung und alle dieselbe Tatsache .
In diesem Punkt sollten doppelte Zeilen aus mehreren Gründen verworfen werden. Aus theoretischer Sicht muss der Designer sicherstellen, dass jede Zeile immer eindeutig ist, um Tabellen zu haben, die so relational arbeiten, wie es die SQL-Datensubsprache zulässt (mit wichtigen Auswirkungen auf Datenmanipulationsvorgänge). Außerdem ist aus informativer Sicht, wenn mehrere Zeilen dieselbe Tatsache darstellen, ihre Aufzeichnung nicht nur überflüssig, sondern auch schädlich , wie unten dargestellt:
- Angenommen, jemand hat zwei identische Zeilen in eine bestimmte Tabelle eingefügt.
- Später kommt jemand anderes und aktualisiert nur ein Vorkommen der Duplikate. Infolgedessen ist das andere Ereignis nicht mehr aktuell.
- Nacheinander aktualisiert eine andere Person das Ereignis, das bisher nicht geändert wurde. Auf diese Weise haben beide Duplikate zu unterschiedlichen Zeitpunkten unterschiedliche Änderungen erfahren.
- Wenn jemand danach interessiert ist, die von den betreffenden Zeilen übermittelten Informationen auszuwählen, kann er oder sie zwei verschiedene „Versionen“ davon finden.
Auf diese Weise:
- Welche „Version“ kann als die richtige, zuverlässige angesehen werden?
- Welches spiegelt die reale Welt genau wider?
Wie Sie wissen, kann dieses Phänomen sogar rechtliche Auswirkungen haben, ein Umstand, der sicherlich von enormer Bedeutung ist.
Außerdem sollte der Zeit- und Arbeitsaufwand für den Umgang mit solchen Widersprüchen (möglicherweise durch eine Art „Aktualisierungssynchronisierung“) besser für Aufgaben aufgewendet werden, die tatsächlich einen Wert für Ihr Unternehmen schaffen. Das Beibehalten widersprüchlicher Zeilen sollte daher vom Design her vermieden werden , um die Konsistenz einer Datenbank aufrechtzuerhalten.
Aus diesem Grund sollte die Identifizierung eines PRIMARY KEY (PK) und die Deklaration der jeweiligen Einschränkung immer vom Datenbankdesigner durchgeführt werden. Es muss jedoch auch erwähnt werden, dass eine Tabelle mehr als eine Spalte oder eine Kombination von Spalten enthalten kann, die Werte enthalten, die jede Zeile eindeutig identifizieren. Infolgedessen muss der Designer neben der Einrichtung einer PK-Einschränkung (idealerweise aus pragmatischen Gründen als PRIMARY festgelegt) auch einen oder mehrere ALTERNATE KEYs (normalerweise definiert über eine oder mehrere UNIQUE plus NOT NULL-Einschränkungen) deklarieren, wenn dies zutrifft (dh ziemlich häufig).
Eine weitere vorteilhafte Eigenschaft von PKs besteht darin, dass sie bei einer „Migration“ in andere Tabellen zur Teilnahme an einzelnen oder zusammengesetzten FKs dazu beitragen können, die Kardinalitätsverhältnisse der zwischen den Daten bestehenden Beziehungen durchzusetzen . All dies, ja, durch einfache und effiziente deklarative Einstellungen, die vom DBMS sichergestellt werden.
(Aktuelle) CHECK-Einschränkungen und einzeilige Validierung
Vergessen wir nicht die Relevanz von (aktuellen) CHECK-Einschränkungen, die durch die deklarative Einschränkung des gültigen Satzes von Spaltenwerten einer Zeile (die einfach erscheinen mag, aber tatsächlich ein grundlegendes Merkmal eines relationalen DBMS ist) ebenfalls hilfreich sind sicher, dass die Regeln des Geschäftskontexts jederzeit präzise wiedergegeben werden.
Da Sie Ihre Frage mit dem MySQL-Tag markiert haben, muss erwähnt werden, dass eine solche Plattform leider die Deklaration dieser Art von Einschränkung zulässt, aber gleichzeitig deren Durchsetzung ignoriert! Eine Situation, die verständlicherweise seit 2004 als Fehler gemeldet wurde .
In diesem Zusammenhang würden Sie kümmern sich um diesen Faktor durch andere Mittel nehmen, zB ACID - Transaktionen , Triggern oder andere Methoden innerhalb des DBMS selbst (siehe diese Antwort von @ ypercubeᵀᴹ
für Informationen zu diesem Thema) , so dass die Daten weiter konsequent sein.
ASSERTION-Einschränkungen: Weitere deklarative Einrichtung weiterer Geschäftsregeln für mehrere Zeilen und Tabellen
Ein Aspekt, der aus welchen Gründen auch immer - wenn überhaupt - von den verschiedenen SQL-DBMS, einschließlich MySQL, nur sehr schlecht unterstützt wird, ist die deklarative Aktivierung von Einschränkungen für mehrere Zeilen und mehrere Tabellen - offensichtlich jenseits von PKs und FKs -.
Der SQL-Standard enthält seinerseits ASSERTIONs aus vielen Jahren. Ich weiß nicht, welche Regeln Ihrer Geschäftsumgebung von diesem Validierungsansatz auf logischer Ebene profitieren würden, aber als Datenbankdesigner halte ich es für ziemlich praktisch, Daten mit einer oder mehreren ASSERTIONs einzuschränken, obwohl ich dies aus dem erwähnen muss Aus Sicht der DBMS-Entwickler war es auf der physischen Abstraktionsebene schwierig, dieses überragende Tool zu implementieren.
Es scheint, dass der Oracle-Anbieter und / oder die Entwickler die ASSERTION-Unterstützung seit 2016 evaluieren. Dies würde das DBMS relationaler und damit robuster und wettbewerbsfähiger machen. Ich denke, wenn (i) ihre Kunden weiter pushen und (ii) Oracle die Implementierung erfolgreich durchführt, müssen (iii) andere DBMS-Anbieter / Communities sie ebenfalls aktivieren, und ihre Nutzung beginnt sich zu verbreiten. Das wäre sicherlich ein großer Fortschritt im Bereich der Datenbankverwaltung, und da Dr. Codd eines der markantesten Instrumente ist, hoffe ich persönlich, dass wir dies bald sehen werden.
Datenkonsistenz und Entscheidungsprozess
Wie oben erläutert, ist einer der wichtigsten Aspekte einer RDB, dass sie selbst die Konsistenz der von ihr gespeicherten Daten garantiert , und diese Konsistenz wird nur erfüllt, wenn die RDB die vom Modellierer deklarierten Integritätsbeschränkungen erfüllt.
In dieser Hinsicht ist es obligatorisch zu haben Basistabellen (die in einer DDL - Struktur festgelegt) , die Integrität geschützt , um in der Lage sein zu schaffen abgeleitete Tabellen (zB eine SELECT - Anweisung oder Ansicht , die abruft Spalten aus mehreren Tabellen), die vertrauenswürdig , weil abgeleitete Tabellen unbedingt in Form von Basistabellen erstellt werden müssen.
Es ist bekannt, dass Menschen Informationen als Hauptinstrument im organisatorischen (und im normalen) Entscheidungsprozess verwenden. Wenn die von einer Datenbank bereitgestellten Informationen nicht kohärent und genau sind, sind die auf diesen Informationen basierenden Entscheidungen (gelinde gesagt) nicht fundiert. Aus diesem Grund muss eine RDB sorgfältig entworfen und implementiert werden: Sie sollte so aufgebaut werden, dass sie zu einer zuverlässigen Ressource wird, die ihren Benutzern hilft, fundierte Entscheidungen zu treffen.
"Denormalisierung"
Leider ist „eine denormalisierte Datenbank schneller als eine normalisierte“ ein weit verbreitetes Missverständnis, obwohl es auch ein Argument ist, das aus logischen, physischen und pragmatischen Gründen widerlegt werden kann.
Erstens impliziert die Denormalisierung notwendigerweise, dass eine Basistabelle zuvor normalisiert wurde (aufgrund eines formalen , wissenschaftlich fundierten Verfahrens, das auf der logischen Abstraktionsebene einer Datenbank erfüllt ist).
Unter der Annahme, dass diese Tabelle tatsächlich korrekt normalisiert wurde, wird sie „denormalisiert“ (was im Gegensatz zur formalen Bedeutung des Wortes das Anhängen von Spalten umfasst, die zu anderen Tabellen in einer Anzeige gehören und auch Teil dieser Tabelle sind hoc mode) könnte beispielsweise dazu beitragen, die Verarbeitung nur einer oder einiger bestimmter SELECT-Anweisungen (auf physischer Ebene) zu beschleunigen, während eine solche Vorgehensweise gleichzeitig die Ausführung vieler anderer zugehöriger Daten untergraben könnte Manipulationsoperationen (z. B. mehrere INSERT-, UPDATE-, DELETE- und SELECT-Anweisungen oder Kombinationen davon, die in einer oder mehreren ACID TRANSACTIONS enthalten sind).
Darüber hinaus würde eine Denormalisierung (formell oder informell) Aktualisierungs- / Änderungsanomalien verursachen , die die Kohärenz der Datenbank verschlechtern. Dieses Problem kann durch komplexe, kostspielige und fehleranfällige Verfahren „gelöst“ werden, wenn dies alles verhindert werden kann der Anfang.
Gerüste auf physischer Ebene, die normalisierte und „denormalisierte“ Tabellen unterstützen
Ein logisches (abstraktes) Layout (SQL-DDL-Design), das in der realen Welt verwendet werden soll, enthält eindeutig physische (konkrete) Auswirkungen, die berücksichtigt werden müssen.
Auf diese Weise wäre eine "denormalisierte" Tabelle notwendigerweise "breiter" (mit zusätzlichen Spalten), was bedeutet, dass ihre Zeilen notwendigerweise schwerer wären (was mehr und größere Komponenten auf physikalischer Ebene erfordert), was bedeutet, dass die zugrunde liegenden Rechenprozesse (z (diejenigen, die mit der Festplatte oder dem Speicher zu tun haben) können leicht langsamer werden.
Im Gegensatz dazu wäre eine normalisierte Tabelle, die natürlich „schmaler“ ist (mit weniger Spalten), ein „leichteres“ Element (das von weniger und kleineren physischen Komponenten bedient wird), das sich „schneller verhält“, was die Reihe der damit verbundenen Aktionen beschleunigen würde zB Schreiben und Lesen von Daten.
Unter diesen Umständen ist es sehr praktisch, (a) die relevanten Tabellen formal und umsichtig zu normalisieren, sie als solche beizubehalten und (b) eine Ressource auf physischer Ebene zu verwenden, die den Datenabruf und die Änderungsgeschwindigkeit optimieren kann, z. B. die Implementierung Eine sorgfältige und effiziente Indizierungsstrategie, die die ordnungsgemäße Konfiguration von Software- und Hardwareservern ermöglicht, die Netzwerkbandbreitenfunktionen aktualisiert usw.
Die Funktionsweise der betrachteten Datenbank
Die folgenden Absätze Ihrer Frage haben mit der Geschwindigkeit der Datenabrufvorgänge zu tun:
[A] Wenn das Produkt „funktioniert“, wird gezögert, die Datenbank zu erweitern. Das erste, was mir aufgefallen ist, ist, dass das Laden einer Seite 1 Minute dauert (ja, 60 Sekunden!).
Wenn das Laden einer bestimmten Seite so viel kostet, ist es offensichtlich, dass die Benutzer des Systems keinen guten Service erhalten. Selbst wenn es „funktioniert“, scheint seine Funktionsweise überhaupt nicht optimal zu sein. Dies zeigt, dass Ihre Absichten, die gesamte Umgebung (Datenbank und Apps) effizienter zu gestalten, gut aufrechterhalten werden und eine sehr konstruktive Haltung zeigen.
Selbst wenn die Wissenschaft Sie definitiv unterstützt und Sie daher eine feste Haltung einnehmen sollten, schlage ich vor, die Situation auf diplomatische Weise anzugehen, da sich letztendlich Ihre Arbeitgeber, Kollegen und Sie gemeinsam bemühen, eine vollständige Organisation aufzubauen erfolgreicher. Dies ist daher ein Argument, das Sie hervorheben sollten: Während sie andere Dinge mehr als gut machen, kann die Verbesserung der allgemeinen und spezifischen Datenverwaltungspraktiken erheblich dazu beitragen, mehr organisatorisches und individuelles Wachstum zu erzielen.
Die meisten relevanten Abfragen enthalten JOIN-Operationen, wodurch sie mit großen Datenmengen sehr, sehr, sehr langsam ausgeführt werden (die Datenbank enthält Millionen von Zeilen).
Es ist anzumerken, dass der JOIN-Operator ein wesentliches und leistungsfähiges Element ist, das sich auf die relationale Manipulation von Daten bezieht. Obwohl robustere Plattformen es mit vergleichsweise schnelleren Ausführungen bedienen, ist der von Ihnen beschriebene Umstand höchstwahrscheinlich ein Symptom für ein nicht effizientes Design (auf der konzeptionellen, logischen und physischen Abstraktionsebene). Meine ersten Schätzungen sind also:
- Die INDEX-Einstellungen müssen möglicherweise verbessert werden.
- Die Definitionen der PK- und FK- Spaltentypen und -größen müssen überprüft werden (und ich stimme @Rick James in Bezug auf seine PK- Überlegungen voll und ganz zu , da zusammengesetzte KEYs in den entsprechenden Fällen tendenziell viel effizienter sind als angehängte Surrogate).
- Eine weitere (formale, wissenschaftlich fundierte) Normalisierung könnte dazu beitragen, diese Probleme zu lösen , da JOINs unter den richtigen Umständen (dh in einem gut konzipierten RDB) sehr schnell ausgeführt werden .
Ja, wie @TommCatt in seiner Antwort erwähnt , ändert manchmal ein (logisches) Umschreiben einer Abfrage ihren (physischen) Ausführungsplan und beschleunigt das Lesen / Schreiben von Daten. Dies ist ein Faktor, der unbedingt berücksichtigt werden sollte.