Mysql
 sql >> Datenbank >  >> RDS >> Mysql

einzelne feste Tabelle mit mehreren Spalten im Vergleich zu flexiblen abstrakten Tabellen

Bestimmte Probleme müssen vorher geklärt und gelöst werden wir können in eine vernünftige Diskussion eintreten.

Erforderliche Auflösung

  1. Etiketten
    In einem Beruf, der Präzision erfordert, ist es wichtig, dass wir präzise Bezeichnungen verwenden, um Verwirrung zu vermeiden und damit wir kommunizieren können, ohne langatmige Beschreibungen und Qualifizierungen verwenden zu müssen.

    Was Sie als FixedTables gepostet haben, ist nicht normalisiert . Fairerweise mag es ein Versuch der dritten Normalform sein, aber tatsächlich ist es eine flache Datei, nicht normalisiert (nicht "denormalisiert). Was Sie als AbstractTables gepostet haben, ist, um genau zu sein, Entity-Attribute-Value , das fast, aber nicht ganz, sechste Normalform ist und daher stärker normalisiert ist als 3NF. Vorausgesetzt natürlich, es wird richtig gemacht.

    • Die unnormalisierte Flatfile ist nicht "denormalisiert". Es ist randvoll mit Duplikaten (es wurde nichts unternommen, um sich wiederholende Gruppen und doppelte Spalten zu entfernen oder Abhängigkeiten aufzulösen) und Nullen, es ist in vielerlei Hinsicht ein Leistungsfresser und verhindert Parallelität.

    • Um denormalisiert zu werden, muss es zuerst normalisiert werden, und dann muss die Normalisierung aus gutem Grund ein wenig zurückgenommen werden. Da es von vornherein nicht normalisiert ist, kann es nicht denormalisiert werden. Es ist einfach nicht normalisiert.

    • Es kann nicht gesagt werden, dass es "für Leistung" denormalisiert wird, da es als Leistungsfresser das genaue Gegenteil von Leistung ist. Nun, sie brauchen eine Rechtfertigung für das Fehlen eines formalisierten Designs], und "für Leistung" ist es. Selbst die kleinste formale Prüfung deckte die falsche Darstellung auf (aber nur sehr wenige Leute können liefern, also bleibt es verborgen, bis sie einen Außenstehenden dazu bringen, sich mit dem massiven Leistungsproblem zu befassen).

    • Normalisierte Strukturen funktionieren weitaus besser als nicht normalisierte Strukturen. Stärker normalisierte Strukturen (EAV/6NF) funktionieren besser als weniger normalisierte Strukturen (3NF/5NF).

    • Ich stimme der Stoßrichtung von OMG Ponys zu, aber nicht ihren Bezeichnungen und Definitionen

    • anstatt zu sagen 'nicht "denormalisieren", es sei denn, Sie müssen' , ich sage:'Normalisiert getreu, Punkt' und 'Wenn es ein Leistungsproblem gibt, haben Sie nicht richtig normalisiert' .

  2. Wikipedia
    Die Einträge für Normalformen und Normalisierung bieten falsche Definitionen; sie verwirren die Normalformen; sie fehlen in Bezug auf den Prozess der Normalisierung; und sie geben absurden oder fragwürdigen NFs, die vor langer Zeit entlarvt wurden, gleiches Gewicht. Das Ergebnis ist, dass Wikipedia zu einem bereits verwirrten und kaum verstandenen Thema beiträgt. Verschwenden Sie also keine Zeit.

    Um jedoch fortzufahren, ohne dass dieser Hinweis ein Hindernis darstellt, lassen Sie mich Folgendes sagen.

    • Die Definition von 3NF ist stabil und hat sich nicht geändert.
    • Es gibt eine Menge Verwirrung der NFs zwischen 3NF und 5NF. Die Wahrheit ist, dass dies ein Bereich ist, der sich in den letzten 15 Jahren weiterentwickelt hat; und viele Organisationen, Akademiker sowie Anbieter mit ihren Produkten mit Einschränkungen, haben sofort ein neues „Normalformular“ erstellt, um ihre Angebote zu validieren. Alle dienen kommerziellen Interessen und sind akademisch ungesund. 3NF in seinem ursprünglichen unverfälschten Zustand beabsichtigt und bestimmte Eigenschaften garantiert.
    • Die Summe ist, 5NF ist heute das, was 3NF vor 15 Jahren sein sollte, und Sie können das kommerzielle Geplänkel und die zwölf oder so "speziellen" (kommerziellen und pseudoakademischen) NFs dazwischen, einige, überspringen von denen in Wikipedia identifiziert werden, und sogar das in verwirrenden Begriffen.

  3. Fünfte Normalform
    Da Sie die EAV in Ihrem Beitrag verstehen und umsetzen konnten, werden Sie kein Problem haben, das Folgende zu verstehen. Natürlich ist ein echtes relationales Modell Voraussetzung, starke Schlüssel usw. Fünfte Normalform ist, da wir die Vierte überspringen:

    • Dritte Normalform
      • was in einfachen, endgültigen Begriffen bedeutet, dass jede Nicht-Schlüsselspalte in jeder Tabelle eine 1::1-Beziehung zum Primärschlüssel der Tabelle hat,
      • und zu keinen anderen Nichtschlüsselspalten
    • Keine Datenduplizierung (das Ergebnis, wenn die Normalisierung sorgfältig vorangetrieben wird; nicht allein durch Intelligenz oder Erfahrung erreicht, oder durch Hinarbeiten als Ziel ohne den formalen Prozess)
    • keine Aktualisierungsanomalien (wenn Sie irgendwo eine Spalte aktualisieren, müssen Sie nicht dieselbe Spalte an einer anderen Stelle aktualisieren; die Spalte existiert an einem und nur einem Ort).
    • Wenn Sie das oben Gesagte verstehen, können 4NF, BCNF und all die dummen "NFs" abgetan werden, sie sind für physischisierte Aufzeichnungsablagesysteme erforderlich, wie sie von Akademikern gefördert werden und dem relationalen Modell (Codd) ziemlich fremd sind.

  4. Sechste Normalform

    • Zweck ist die Beseitigung fehlender Daten (Attributspalten), auch bekannt als Eliminierung von Nullen
    • Dies ist die einzig wahre Lösung für das Null-Problem (auch Umgang mit fehlenden Werten genannt), und das Ergebnis ist eine Datenbank ohne Nullen. (Es kann bei 5NF mit Standards und Null-Ersatzwerten gemacht werden, aber das ist nicht optimal.) Wie Sie die fehlenden Werte interpretieren und anzeigen, ist eine andere Geschichte.
    • Technisch gesehen ist es keine echte Normalform, weil es keine 5NF als Voraussetzung hat, aber es hat einen Wert

  5. EAV vs. Sechste Normalform
    Alle Datenbanken, die ich geschrieben habe, außer einer, sind reines 5NF. Ich habe mit einigen EAV-Datenbanken gearbeitet (verwaltet, repariert, erweitert) und viele echte 6NF-Datenbanken implementiert. EAV ist eine lockere Implementierung von 6NF, die häufig von Personen durchgeführt wird, die die Normalisierung und die NFs nicht gut verstehen, aber den Wert von EAV erkennen und die Flexibilität von EAV benötigen. Sie sind ein perfektes Beispiel.

    Der Unterschied ist folgender:Weil es lose ist und Implementierer keine Referenz (6NF) haben, der sie treu bleiben können, implementieren sie nur das, was sie brauchen, und sie schreiben alles in Code; das ist am Ende ein inkonsistentes Modell.

    Dagegen hat eine reine 6NF-Implementierung einen rein akademischen Bezugspunkt und ist daher normalerweise straffer und konsistenter. Typischerweise zeigt sich dies in zwei sichtbaren Elementen:

    • 6NF hat einen Katalog, der Metadaten enthält, und alles wird in Metadaten definiert, nicht im Code. EAV hat keinen, alles ist im Code (Implementierer verfolgen die Objekte und Attribute). Offensichtlich erleichtert ein Katalog das Hinzufügen von Spalten, die Navigation und ermöglicht die Bildung von Dienstprogrammen.
    • 6NF liefert, wenn es verstanden wird, die wahre Lösung für das Nullproblem. EAV-Implementierer behandeln fehlende Daten im Code, da ihnen der 6NF-Kontext fehlt, inkonsistent, oder schlimmer noch, sie lassen Nullwerte in der Datenbank zu. 6NF-Implementierer verbieten Nullen und behandeln fehlende Daten konsistent und elegant, ohne dass Code-Konstrukte erforderlich sind (für die Null-Behandlung; Sie müssen natürlich immer noch für fehlende Daten codieren).

Z.B. Für 6NF-Datenbanken mit einem Katalog habe ich eine Reihe von Procs, die das SQL [neu] generieren, das zum Ausführen aller SELECTs erforderlich ist, und ich stelle Ansichten in 5NF für alle Benutzer bereit, sodass sie die zugrunde liegende 6NF-Struktur nicht kennen oder verstehen müssen . Sie werden aus dem Katalog vertrieben. Änderungen sind somit einfach und automatisiert. EAV-Typen tun dies manuell, da kein Katalog vorhanden ist.

Diskussion

Jetzt können wir die Diskussion beginnen.

"Natürlich kann es abstrakter sein, wenn Werte vordefiniert sind (Beispiel:Spezialitäten könnten ihre eigene Liste haben)"

Sicher. Aber werde nicht zu "abstrakt". Achten Sie auf Konsistenz und implementieren Sie solche Listen auf die gleiche EAV- (oder 6NF-) Weise wie andere Listen.

"Wenn ich den abstrakten Ansatz wähle, kann er sehr flexibel sein, aber Abfragen werden mit vielen Verknüpfungen komplexer. Aber ich weiß nicht, ob sich dies auf die Leistung auswirkt, wenn diese 'komplexeren' Abfragen ausgeführt werden."

  1. Joins sind in relationalen Datenbanken Fußgänger. Das Problem ist nicht die Datenbank, das Problem ist, dass SQL bei der Handhabung von Verknüpfungen umständlich ist, insbesondere bei zusammengesetzten Schlüsseln.

  2. EAV- und 6NF-Datenbanken haben mehr Joins, die genauso wie Fußgänger sind, nicht mehr und nicht weniger. Wenn Sie jedes SELECT manuell codieren müssen, wird das Umständliche wirklich umständlich.

  3. Das gesamte Problem kann beseitigt werden, indem (a) 6NF über EAV verwendet wird und (b) ein Katalog implementiert wird, aus dem Sie (c) das gesamte grundlegende SQL generieren können. Beseitigt auch eine ganze Klasse von Fehlern.

  4. Es ist ein verbreiteter Mythos, dass Joins irgendwie etwas kosten. Völlig falsch.

    • Der Join wird zur Kompilierzeit implementiert, es gibt nichts Wesentliches, was CPU-Zyklen 'kosten' könnte.
    • Das Problem ist die Größe der Tabellen verbunden werden, nicht die Kosten des Joins zwischen denselben Tabellen.
    • Verbinden von zwei Tabellen mit jeweils Millionen von Zeilen in einer korrekten PK⇢FK-Beziehung, von denen jede die entsprechenden Indizes hat
      (Eindeutig auf der übergeordneten [PK]-Seite; Eindeutig auf der untergeordneten Seite [PK=parent FK + etwas]
      ist sofort
    • Wenn der untergeordnete Index nicht eindeutig ist, aber zumindest die führenden Spalten gültig sind, ist er langsamer; wo es keinen nützlichen Index gibt, ist es natürlich sehr langsam.
    • Nichts davon hat mit den Beitrittskosten zu tun.
    • Wenn viele Zeilen zurückgegeben werden, ist der Engpass das Netzwerk und das Plattenlayout; nicht die Join-Verarbeitung.

  5. Daher können Sie so "komplex" werden, wie Sie möchten, es entstehen keine Kosten, SQL kann damit umgehen.

Mich würde interessieren, was die Vor- und Nachteile beider Methoden sind. Ich kann es mir selbst vorstellen, aber ich habe nicht die Erfahrung, um dies zu bestätigen.

  1. 5NF (oder 3NF für diejenigen, die die Progression nicht gemacht haben) ist in Bezug auf die Implementierung am einfachsten und besten; Benutzerfreundlichkeit (sowohl Entwickler als auch Benutzer); und Wartung.

    • Der Nachteil ist, dass Sie jedes Mal, wenn Sie eine Spalte hinzufügen, die Datenbankstruktur (Tabelle DDL) ändern müssen. Das ist in manchen Fällen in Ordnung, aber nicht in den meisten Fällen, da Änderungskontrollen vorhanden sind, ziemlich mühsam.
    • Zweitens müssen Sie bestehenden Code ändern (Code, der die neue Spalte behandelt, zählt nicht, weil das zwingend erforderlich ist):Wo gute Standards implementiert sind, wird das minimiert; Wo sie fehlen, ist der Umfang unvorhersehbar.

  2. EAV (was Sie gepostet haben) ermöglicht das Hinzufügen von Spalten ohne DDL-Änderungen. Das ist der einzige Grund, warum die Leute es wählen. (Code, der die neue Spalte behandelt, zählt nicht, da dies zwingend erforderlich ist). Bei guter Implementierung wirkt sich dies nicht auf bestehenden Code aus. wenn nicht, wird es.

  3. Aber Sie brauchen EAV-fähige Entwickler.

    • Wenn EAV schlecht implementiert ist, ist es abscheulich, ein schlimmeres Durcheinander als 5NF schlecht gemacht, aber nicht schlimmer als Unnormalized, was die meisten Datenbanken da draußen sind (falsch dargestellt als "denormalisiert für Leistung").
    • Natürlich ist es noch wichtiger (als in 5NF/3NF), einen starken Transaktionskontext zu halten, weil die Spalten viel weiter verteilt sind.
    • Ebenso ist es wichtig, die deklarative referenzielle Integrität beizubehalten:Die Unordnung, die ich gesehen habe, war zum großen Teil darauf zurückzuführen, dass die Entwickler DRI entfernt haben, weil es "zu schwer zu warten" wurde, das Ergebnis war, wie Sie sich vorstellen können, eine Mutter eines Datenhaufens mit doppelten 3NF/5NF-Zeilen und -Spalten überall. Und inkonsistente Nullbehandlung.

  4. Es gibt keinen Leistungsunterschied, vorausgesetzt, der Server wurde für den beabsichtigten Zweck angemessen konfiguriert. (Ok, es gibt spezifische Optimierungen, die nur in 6NF möglich sind, die in anderen NFs nicht möglich sind, aber ich denke, das würde den Rahmen dieses Threads sprengen.) Und wieder kann ein schlecht gemachtes EAV unnötige Engpässe verursachen, nicht mehr als Nicht normalisiert.

  5. Wenn Sie sich für EAV entscheiden, empfehle ich natürlich mehr Formalität; kaufe das volle Pfund; gehen Sie mit 6NF; einen Katalog implementieren; Dienstprogramme zum Erstellen von SQL; Ansichten; Gehen Sie konsequent mit fehlenden Daten um; eliminieren Sie Nullen vollständig. Dies reduziert Ihre Anfälligkeit für die Qualität Ihrer Entwickler; Sie können die esoterischen Probleme von EAV/6NF vergessen, Views verwenden und sich auf die App-Logik konzentrieren.