Nein, das ist ein schlechtes Design für eine relationale Datenbank. Dies ist ein Beispiel für den Entity-Attribute-Value Design. Es ist flexibel, aber es bricht die meisten Regeln dessen, was es bedeutet, eine relationale Datenbank zu sein.
Bevor Sie sich mit dem EAV-Design als Lösung für eine flexible Datenbank befassen, lesen Sie diese Geschichte:Schlechtes CaRMa .
Einige der Probleme mit EAV beinhalten insbesondere:
- Sie wissen nicht, welche Attribute für eine bestimmte ID_NUM existieren, ohne danach zu fragen.
- Sie können kein Attribut obligatorisch machen, das Äquivalent von NOT NULL.
- Sie können keine Datenbankeinschränkungen verwenden.
- Sie können keine SQL-Datentypen verwenden; der
valueSpalte muss ein langer VARCHAR sein. - Besonders in MySQL wird jedes VARCHAR auf einer eigenen Datenseite gespeichert, also ist dies sehr verschwenderisch.
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, dass es sehr langsam und schwer abzufragen ist, 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.
Mehr über EAV habe ich in meiner Präsentation Practical Object-Oriented geschrieben Modelle in SQL und in meinem Blogbeitrag EAV FAIL , und in meinem Buch SQL Antipatterns:Avoiding the Pitfalls of Database Programming .
