Varför? Gör allt behöver dina enheter vara utbyggbara på detta sätt? Förmodligen inte -- i de flesta applikationer finns det högst en eller två enheter som skulle dra nytta av denna flexibilitetsnivå. De andra enheterna drar faktiskt nytta av stabiliteten och tydligheten inte ändras hela tiden.
EAV är ett exempel på Inner-Platform Effect :
Med andra ord, nu är det ditt ansvar att skriva applikationskod för att göra alla saker som en riktig RDBMS redan tillhandahåller, som begränsningar och datatyper. Till och med något så enkelt som att göra en kolumn obligatorisk som NOT NULL fungerar inte i EAV.
Det är sant att ett projekt ibland kräver många tabeller. Men du lurar dig själv om du tror att du har förenklat projektet genom att bara göra två tabeller. Du kommer fortfarande att ha lika många distinkta enheter som du skulle ha haft bord, men nu är det upp till dig att förhindra att de förvandlas till en hög med skräp.
Innan du investerar för mycket tid i EAV, läs den här historien om ett företag som nästan slutade fungera eftersom någon försökte göra sitt datalager godtyckligt flexibelt:Bad CarMa .
Jag skrev också mer om EAV i ett blogginlägg, EAV FAIL , och i ett kapitel i min bok, SQL Antipatterns:Avoiding the Pitfalls of Database Programming .