Nej, dette er et dårligt design til en relationel database. Dette er et eksempel på Entity-Attribute-Value design. Det er fleksibelt, men det bryder de fleste regler for, hvad det vil sige at være en relationel database.
Før du går ned i EAV-designet som en løsning til en fleksibel database, skal du læse denne historie:Dårlig CarMa .
Mere specifikt omfatter nogle af problemerne med EAV:
- Du ved ikke, hvilke attributter der findes for et givet ID_NUM uden at forespørge efter dem.
- Du kan ikke gøre nogen egenskab obligatorisk, svarende til NOT NULL.
- Du kan ikke bruge databasebegrænsninger.
- Du kan ikke bruge SQL-datatyper;
valuekolonne skal være en lang VARCHAR. - Især i MySQL er hver VARCHAR gemt på sin egen dataside, så dette er meget spild.
Forespørgsler er også utroligt komplekse, når du bruger EAV-designet. Magento, en open source e-handelsplatform, bruger EAV i vid udstrækning, og mange brugere siger, at det er meget langsomt og svært at forespørge, hvis du har brug for tilpassede rapporter.
For at være relationel bør du gemme hver af de forskellige attributter i sin egen kolonne med sit eget navn og en passende datatype.
Jeg har skrevet mere om EAV i min præsentation Praktisk objektorienteret Modeller i SQL og i mit blogindlæg EAV FAIL , og i min bog, SQL Antipatterns:Avoiding the Pitfalls of Database Programming .