Integritätsbeschränkungen in einer relationalen Datenbank - sollten wir sie übersehen?

10

Ich bin in einer permanenten Diskussion mit den Entwicklern des Unternehmens, in dem ich arbeite, weil sie sagen, dass es besser ist, die Durchsetzung von Beziehungen (über FOREIGN KEY-Einschränkungsdefinitionen) in einer relationalen Datenbank zu beseitigen, um große Abfragen zu beschleunigen und bessere Ergebnisse zu erzielen Performance.

Die betrachtete Plattform ist MySQL 5.x, und es wurde kein FOREIGN KEY eingerichtet. Es fehlen sogar einige PRIMARY KEY-Einschränkungen der relevanten Tabellen, was zumindest für mich nicht sinnvoll ist. Vielleicht haben sie Recht und ich liege falsch, aber ich habe nicht genug Argumente, um über diese Situation zu diskutieren.

Dies ist seit drei Jahren der bevorzugte Ansatz. Ich bin neu in dieser Firma (nur einen Monat), aber da das Produkt „funktioniert“, gibt es Bedenken, die Datenbank zu verbessern. Trotzdem ist mir als erstes aufgefallen, dass eine Seite 1 Minute zum Laden benötigt (ja, 60 Sekunden!).

Eine der Behauptungen hinter dem aktuellen Stand der Dinge ist, dass eine „denormalisierte“ Datenbank schneller ist als eine normalisierte, aber ich glaube nicht, dass das stimmt.

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).

Üblicherweise wird die Behandlung von "CRUD" -Operationen auf der Ebene des Anwendungsprogrammcodes implementiert. Um beispielsweise einige Daten von zu löschen, sagen wir TableA:

  • Es ist notwendig, zuerst im laufenden Betrieb zu überprüfen , ob eine Beziehung zwischen den Zeilen von TableAund TableBbesteht.
  • Falls diese Beziehung "erkannt" wird, erlaubt der App-Programmcode nicht, die entsprechenden Zeilen zu löschen, aber
  • Wenn der App-Programmcode aus irgendeinem Grund fehlschlägt, ist die DELETE-Operation „erfolgreich“, unabhängig davon, ob eine Beziehung zu den beteiligten Zeilen und Tabellen besteht.

Frage

Könnten Sie mir helfen, eine gute, genaue und solide Antwort zu finden, um die Debatte zu bereichern?


Hinweis : Möglicherweise wurde so etwas schon einmal gefragt (und beantwortet), aber ich konnte mithilfe von Google nichts finden.

ReynierPM
quelle
Kommentare sind nicht für eine ausführliche Diskussion gedacht. Dieses Gespräch wurde in den Chat verschoben .
Paul White 9

Antworten:

12

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.

MDCCL
quelle
1
Gute Antwort. Ich erinnere mich immer daran, wenn ich die Leistung einer Implementierung betrachte, dass ein Entwicklerteam viel schlauer ist, als ich seit sehr langer Zeit an diesen Problemen arbeite. Relationale Datenbanken sind das Herzstück der größten Systeme der Welt (Facebook und Twitter, um nur einige offensichtliche zu nennen).
Nick Bedford
9

Die Grundvoraussetzung Ihrer Entwickler ist absolut falsch. Fremdschlüssel wirken sich geringfügig auf die Leistung der DML Ihres Systems aus. Sie werden in Abfragen überhaupt nicht verwendet und haben daher keinen Einfluss auf ihre Leistung. Ihre Entwickler wissen also nicht, wovon sie sprechen, und sind die allerletzten Personen, bei denen Sie sich beraten lassen sollten.

Fremdschlüssel spielen eine entscheidende Rolle bei der Aufrechterhaltung der Integrität Ihrer Daten. Dies ist viel wichtiger als jede winzige Leistungsverbesserung, die durch das Entfernen erzielt wird (selbst wenn dies zutrifft).

Entfernen Sie unter keinen Umständen FKs aus einer OLTP-Datenbank.

Das Denormalisieren beschleunigt manchmal auch einige Abfragen. Es kommt darauf an, wie sie sagen. Selbst wenn sich die Geschwindigkeit verbessert, lohnt sich der zusätzliche Aufwand zur Aufrechterhaltung der Datenintegrität im Allgemeinen nicht.

Es ist sehr selten, wenn durch einfaches Einstellen nicht viel mehr Geschwindigkeit verbessert werden kann als durch Denormalisieren. Hier kann ein guter DBA (endlich) seinen Lohn verdienen. Sie können Ihre Abfragen auch optimieren. Ich habe einmal eine Anfrage beantwortet, die in nicht weniger als 30 Minuten eine Antwort ergab, und sie in weniger als 8 Sekunden zum Laufen gebracht. Keine Änderungen an der Datenbank, schreiben Sie einfach die Abfrage neu. Zugegeben, dies ist meine persönliche Bestleistung, daher kann Ihr Kilometerstand variieren, aber die Denormalisierung sollte das allerletzte sein, was Sie versuchen.

Möglicherweise möchten Sie auch verhindern, dass die Entwickler kompliziertere Abfragen schreiben. Fragen Sie sie, welche Daten sie möchten und in welchem ​​Format sie sie haben möchten. Geben Sie dann Ansichten an, um sie ihnen zu geben. Die komplizierten Abfragen werden die Ansichten sein. Die Entwickler müssen dann nur noch schreiben:

select <something> from <SomeView> where <whatever>;

Ich gehe auch davon aus, dass Ihre Datenbank ansonsten gut gestaltet ist. Ein schlechtes Design der Datenbank oder sogar kleiner Teile davon kann die Dinge wirklich verlangsamen. Ich habe oft mit sehr großen Tabellen (jeweils Milliarden von Datensätzen) mit Abfragen gearbeitet, die sie links und rechts zusammenfügten und Antworten in Bruchteilen von Sekunden erwarteten (und erhielten). Die Größe einer Tabelle bestimmt nicht die Geschwindigkeit der Abfrage.

Ich erschrecke wirklich, wenn jemand sagt: "Weil das Produkt" funktioniert ", zögert man, die Datenbank zu verbessern." Wenn dieses "Zögern" eher wie "nicht auf meiner Uhr, Kumpel!" Dann möchten Sie vielleicht sogar mit der Aktualisierung Ihres Lebenslaufs beginnen. Aus einer solchen Umgebung kommt nie etwas Gutes, und Sie werden für jeden zukünftigen Fehler verantwortlich gemacht, obwohl Sie sich möglicherweise stundenlang dafür eingesetzt haben, eine Änderung vorzunehmen, die den Fehler verhindert hätte. Sie werden immer wieder hören: "Jetzt ist kein guter Zeitpunkt, um Änderungen vorzunehmen". Richtig. Viel Glück.

TommCatt
quelle
Beachten Sie, dass Sie manchmal unterschiedliche Abfragen für dieselben Daten benötigen, basierend auf der Menge der zurückzugebenden Daten. Beispielsweise kann eine Abfrage, die eine einzelne Zeile (oder sogar nur eine Anzahl) zurückgibt, besser anders geschrieben werden als eine Abfrage, die Tausende von Datensätzen zurückgibt.
Joe W
2

Durch Ändern des Titels wird die Frage geändert. FOREIGN KEYssind optional. Tun sie:

  • Ein FK erstellt implizit ein INDEXin einer der Tabellen. Ein solcher Index kann manuell hinzugefügt werden. (FK ist dafür also nicht erforderlich .)
  • Ein FK prüft auf Integrität. Dies ist der Hauptanspruch der FK auf Ruhm. Eine FK ist nicht erforderlich, da Ihre Anwendung ähnliche Prüfungen durchführen oder entscheiden kann, dass eine Prüfung nicht erforderlich ist. So...
  • Die Integritätsprüfung kostet etwas an Leistung. so verlangsamt es die Verarbeitung. (Dies ist normalerweise keine große Sache.)
  • FKs machen nicht alles, was jeder will; Dieses Forum ist übersät mit Fragen, warum FKs keine X machen können. Insbesondere wird auf die CHECKOption nicht reagiert.
  • FKs können CASCADEDinge. (Ich persönlich ziehe es vor, die Kontrolle zu behalten und nicht davon auszugehen, dass die FK das Richtige tut.)

Fazit für FKs: Einige Leute bestehen auf FKs; Einige Produkte leben ohne sie perfekt. Du entscheidest.

PRIMARY KEYIn InnoDB loszuwerden ist ein großer Fehler. Auf der anderen Seite AUTO_INCREMENTist es oft richtig , einen Ersatz loszuwerden und eine "natürliche" PK zu verwenden, die aus einer (oder mehreren) Spalten besteht . Ein einfacher, häufiger Fall ist eine Mapping-Tabelle mit vielen: vielen, wie hier erläutert .

Aufgrund persönlicher Erfahrungen schlage ich vor, dass 2/3 der Tabellen besser 'natural' als auto_inc PK verwenden.

Rick James
quelle
1
Also ... Sie verlassen sich auf eine nahezu perfekte Anwendung, denn wenn ein Entwickler beispielsweise einen Fehler mit einer macht DELETEund Sie keine Einschränkung auf der DB-Seite haben, werden Sie Daten verlieren. Dieser Ansatz ist gültig, erfordert aber intensiven Code und gute Tests, die sie nicht hatten :)
ReynierPM
Zu viel Löschen kann in der App oder mit FK passieren. Zu wenig zu löschen wird normalerweise offensichtlich. OTOH, ich habe Fälle gesehen, in denen zu wenig Löschen die Kosten wert ist - denken Sie an eine "Normalisierung", bei der Dinge selten gelöscht werden. Die zusätzlichen, nicht verwendeten Zeilen sind praktisch harmlos.
Rick James
Ich habe einen "guten" Fall für keine Indizes in einer Tabelle gesehen - eine Staging-Tabelle für die schnelle Aufnahme. Es ist sehr vorübergehend (daher wird InnoDB nicht benötigt) und muss nur vollständig gelesen werden (daher werden keine Indizes benötigt).
Rick James
1
Beachten Sie ein allgemeines Thema in meinen Streifzügen: Es gibt keine einzige Antwort; Keine Einheitsgröße.
Rick James
Wenn Ihre Tabellen tausend Zeilen lang sind; Leistung ist kein Problem. Wenn Ihre Tabellen eine Milliarde Zeilen lang sind, müssen alle "Regeln" für Normalisierung, PKs, Indizes, FKs, UUIDs usw. überprüft werden. Sonst schmilzt die Datenbank.
Rick James