Come mai? Fai tutto le tue entità richiedono di essere estensibili in questo modo? Probabilmente no:nella maggior parte delle applicazioni ci sono al massimo una o due entità che trarrebbero vantaggio da questo livello di flessibilità. Le altre entità beneficiano effettivamente della stabilità e della chiarezza di non cambiando continuamente.
EAV è un esempio dell'Inner-Platform Effect :
In altre parole, ora è tua responsabilità scrivere il codice dell'applicazione per eseguire tutte le cose già fornite da un RDBMS adeguato, come vincoli e tipi di dati. Anche qualcosa di semplice come rendere obbligatoria una colonna come NOT NULL non funziona in EAV.
È vero a volte un progetto richiede molti tavoli. Ma ti stai prendendo in giro se pensi di aver semplificato il progetto realizzando solo due tabelle. Avrai ancora tante Entità distinte quante avresti avuto tavoli, ma ora sta a te impedire che si trasformino in un mucchio di spazzatura.
Prima di investire troppo tempo in EAV, leggi questa storia su un'azienda che ha quasi smesso di funzionare perché qualcuno ha cercato di rendere arbitrariamente flessibile il proprio repository di dati:Bad CaRMa .
Ho anche scritto di più su EAV in un post sul blog, EAV FAIL e in un capitolo del mio libro, SQL Antipatterns:evitare le insidie della programmazione di database .
