Waarom? Doe alles uw entiteiten op deze manier uitbreidbaar moeten zijn? Waarschijnlijk niet -- in de meeste toepassingen zijn er hoogstens een of twee entiteiten die baat zouden hebben bij dit niveau van flexibiliteit. De andere entiteiten profiteren juist van de stabiliteit en duidelijkheid van niet verandert voortdurend.
EAV is een voorbeeld van het Inner-Platform Effect :
Met andere woorden, nu is het jouw verantwoordelijkheid om applicatiecode te schrijven om alle dingen te doen die een goed RDBMS al biedt, zoals beperkingen en gegevenstypen. Zelfs zoiets eenvoudigs als het verplicht maken van een kolom zoals NOT NULL werkt niet in EAV.
Het is waar dat een project soms veel tabellen vereist. Maar je houdt jezelf voor de gek als je denkt dat je het project vereenvoudigd hebt door slechts twee tabellen te maken. Je zult nog steeds net zoveel verschillende entiteiten hebben als je aan tafels zou hebben gehad, maar nu is het aan jou om te voorkomen dat ze veranderen in een hoop afval.
Voordat u te veel tijd in EAV investeert, leest u dit verhaal over een bedrijf dat bijna ophield te functioneren omdat iemand probeerde zijn gegevensopslag willekeurig flexibel te maken:Slechte CaRMa .
Ik schreef ook meer over EAV in een blogpost, EAV FAIL , en in een hoofdstuk van mijn boek, SQL Antipatterns:Avoiding the Pitfalls of Database Programming .