Nej, detta är en dålig design för en relationsdatabas. Det här är ett exempel på Entity-Attribute-Value design. Det är flexibelt, men det bryter mot de flesta regler för vad det innebär att vara en relationsdatabas.
Innan du går ner i EAV-designen som en lösning för en flexibel databas, läs den här historien:Bad CarMa .
Mer specifikt inkluderar några av problemen med EAV:
- Du vet inte vilka attribut som finns för ett givet ID_NUM utan att fråga efter dem.
- Du kan inte göra något attribut obligatoriskt, motsvarande NOT NULL.
- Du kan inte använda databasbegränsningar.
- Du kan inte använda SQL-datatyper;
valuekolumnen måste vara en lång VARCHAR. - Särskilt i MySQL lagras varje VARCHAR på sin egen datasida, så detta är väldigt slösaktigt.
Frågor är också otroligt komplexa när du använder EAV-designen. Magento, en e-handelsplattform med öppen källkod, använder EAV i stor utsträckning, och många användare säger att det är väldigt långsamt och svårt att fråga om du behöver anpassade rapporter.
För att vara relationell bör du lagra varje olika attribut i en egen kolumn, med ett eget namn och en lämplig datatyp.
Jag har skrivit mer om EAV i min presentation Praktisk objektorienterad Modeller i SQL och i mitt blogginlägg EAV FAIL , och i min bok, SQL Antipatterns:Avoiding the Pitfalls of Database Programming .