mysql Tabellenstrukturvorschlag?

Nein, das ist ein schlechter Entwurf für eine relationale Datenbank. Dies ist ein Beispiel für das Design Entity-Attribut-Value . Es ist flexibel, aber es bricht die meisten Regeln, was es bedeutet, eine relationale Datenbank zu sein.

Bevor Sie in das EAV-Design als Lösung für eine flexible Datenbank einsteigen, lesen Sie diese Geschichte: Bad CaRMa .

Genauer gesagt beinhalten einige der Probleme mit EAV:

• Sie wissen nicht, welche Attribute für eine gegebene ID_NUM existieren, ohne nach ihnen zu suchen.
• Sie können keine Attribute als Äquivalent zu NOT NULL festlegen.
• Sie können keine Datenbankeinschränkungen verwenden.
• Sie können keine SQL-Datentypen verwenden. Die Spalte value muss ein langer VARCHAR sein.
• Insbesondere in MySQL ist jeder VARCHAR auf seiner eigenen Datenseite gespeichert, was sehr verschwenderisch ist.

Abfragen sind auch unglaublich komplex, wenn Sie das EAV-Design verwenden. Magento, eine Open-Source-E-Commerce-Plattform, verwendet EAV ausgiebig, und viele Benutzer sagen, es ist sehr langsam und schwer abzufragen, wenn Sie benutzerdefinierte Berichte benötigen.

Um relational zu sein, sollten Sie jedes unterschiedliche Attribut in einer eigenen Spalte mit einem eigenen Namen und einem geeigneten Datentyp speichern.

Ich habe in meiner Präsentation Practical Object-Oriented Models in SQL und in meinem Blogpost EAV FAIL und in meinem Buch SQL Antipatterns: Vermeiden Sie die Nachteile der Datenbankprogrammierung .

Nach meiner Erfahrung muss diese Idee, Felder zeilenweise zu speichern, sehr sorgfältig betrachtet werden - obwohl es viele Vorteile zu haben scheint, macht es viele allgemeine Aufgaben viel schwieriger.

Auf der positiven Seite: Es ist leicht erweiterbar ohne Änderungen an der Struktur der Datenbank und abstrahiert in gewisser Weise die Details des Datenspeichers.

Auf der negativen Seite: Sie müssen alle alltäglichen Dinge betrachten, die Felder spaltenweise automatisch im DBMS speichern: Einfache innere / äußere Joins, eine Anweisung Einfügungen / Aktualisierungen, Eindeutigkeit, Fremdschlüssel und andere db-Level-Constraints Überprüfung, einfache Filteranzeige Bestellung von Suchergebnissen.

Berücksichtigen Sie in Ihrer Architektur eine Abfrage, um alle Elemente mit MetalLayer = X und Breite zwischen y und z zurückzugeben - Ergebnisse sortiert nach Länge. Diese Abfrage ist viel schwieriger für Sie zu konstruieren und sehr viel schwieriger für das Ausführen des DBMS als das Verwenden von Spalten zum Speichern bestimmter Felder.

In der Bilanz habe ich eine Struktur wie die von Ihnen vorgeschlagene nur in einem Kontext verwendet, in dem zufällige unstrukturierte zusätzliche Daten ad hoc hinzugefügt werden mussten. Meiner Meinung nach wäre dies eine letzte Strategie, wenn es keine Möglichkeit gäbe, eine traditionellere Tischstruktur zu schaffen.

Was Sie vorschlagen, heißt EAV model (Entity–Attribute–Value)

Es hat mehrere Nachteile, wie z. B. schwerwiegende Schwierigkeiten bei der Durchsetzung referenzieller Integritätsbedingungen. Darüber hinaus werden die Abfragen, die Sie aufstellen müssen, etwas komplizierter sein als bei einer normalisierten Tabelle als Ihr zweiter Vorschlag (Tabelle mit Spalten: Primary Key, Width, Length, Space, Coupling, etc ).

Verwenden Sie für ein einfaches Projekt also kein EAV-Modell.

Wenn Sie ein komplexeres Projekt planen und maximale Flexibilität wünschen, sollten Sie auch EAV nicht verwenden. Sie sollten in 6NF (6th Normal Form) schauen, was noch schwieriger zu implementieren und sicherlich keine leichte Aufgabe ist in MySQL. Aber wenn Sie erfolgreich sind, haben Sie beide Güter: Flexibilität und Normalisierung auf höchstem Niveau (manche Leute nennen " EAV " als " 6NF falsch gemacht ").

Hier ein paar Dinge zu beachten:

Es gibt keinen einzelnen Primärschlüssel. Dies kann überwunden werden, indem der Primärschlüssel aus zwei Spalten besteht (wie im zweiten Beispiel von Carl T).

Die Param-Spalte wird wiederholt und um dies zu normalisieren, sollten Sie sich das Beispiel von MGA ansehen.

Drittens ist die Spalte "Metal layer" eine Zeichenfolge und kein float-Wert wie die anderen.

Also am besten für einen Tisch Def wie folgt gehen:

Die wichtigste Frage, die Sie beim Erstellen einer Tabelle speziell für die zukünftige Verwendung stellen müssen, ist, wie diese Daten abgerufen werden und welchen Zweck sie haben. Persönlich habe ich immer eine eindeutige Kennung, normalerweise eine ID für die Tabelle.

Wenn Sie auf die Liste schauen, scheint nichts vorhanden zu sein, das die Einträge eindeutig definiert, so dass Sie doppelte Einträge nicht verfolgen und keinen Datensatz eindeutig abrufen können.

Wenn Sie dieses Design beibehalten möchten, können Sie einen zusammengesetzten Primärschlüssel erstellen, der aus dem Namen und dem Parameterwert besteht.

Diese Tabelle zum Erstellen einer Tabelle drückt die zwei oben genannten Optionen aus.