Nee, dit is een slecht ontwerp voor een relationele database. Dit is een voorbeeld van de Entity-Attribute-Value ontwerp. Het is flexibel, maar het overtreedt de meeste regels van wat het betekent om een relationele database te zijn.
Lees dit verhaal voordat je afdaalt in het EAV-ontwerp als oplossing voor een flexibele database:Slechte CaRMa .
Meer specifiek zijn enkele van de problemen met EAV:
- U weet niet welke kenmerken er zijn voor een bepaalde ID_NUM zonder ernaar te vragen.
- Je kunt geen enkel kenmerk verplicht maken, het equivalent van NOT NULL.
- Je kunt geen databasebeperkingen gebruiken.
- U kunt geen SQL-gegevenstypen gebruiken; de
valuekolom moet een lange VARCHAR zijn. - Vooral in MySQL wordt elke VARCHAR op zijn eigen gegevenspagina opgeslagen, dus dit is erg verspillend.
Query's zijn ook ongelooflijk complex wanneer u het EAV-ontwerp gebruikt. Magento, een open-source e-commerceplatform, maakt veelvuldig gebruik van EAV en veel gebruikers zeggen dat het erg traag en moeilijk is om op te vragen of je aangepaste rapporten nodig hebt.
Om relationeel te zijn, moet u elk verschillend attribuut in zijn eigen kolom opslaan, met zijn eigen naam en een geschikt datatype.
Ik heb meer over EAV geschreven in mijn presentatie Practical Object-Oriented Modellen in SQL en in mijn blogpost EAV FAIL , en in mijn boek, SQL Antipatterns:Avoiding the Pitfalls of Database Programming .