Antimodello?
In casi comuni, la seconda tabella è anti-pattern nel contesto della progettazione di database. E, ancora di più, ha un nome specifico:Entity-Attribute-Value (EAV). Ci sono alcuni casi in cui l'utilizzo di questo design è giustificato, ma sono casi rari e anche lì può essere evitato.
Perché EAV è cattivo
Supporto per l'integrità dei dati
Nonostante il fatto che tale struttura sembri essere più "flessibile" o "avanzata", questo design ha dei punti deboli.
- Impossibile rendere obbligatori gli attributi . Non è possibile rendere obbligatori alcuni attributi, poiché l'attributo è ora archiviato come riga - e l'unico segno che l'attributo non è impostato - è che la riga corrispondente è assente nella tabella. SQL non ti consentirà di creare tale vincolo in modo nativo, quindi dovrai verificarlo nell'applicazione e, sì, interroga la tua tabella ogni volta
- Miscelazione di tipi di dati . Non sarai in grado di utilizzare i tipi di dati standard SQL. Perché la tua colonna del valore deve essere un "super-tipo" per tutti i valori memorizzati in essa. Ciò significa che in generale dovrai archiviare tutti i dati come stringhe grezze . Quindi vedrai quanto è doloroso lavorare con le date come con le stringhe, trasmettere i tipi di dati ogni volta, controllare l'integrità dei dati, ecc.
- Impossibile applicare l'integrità referenziale . In una situazione normale, puoi utilizzare la chiave esterna per limitare i tuoi valori a quelli definiti nella tabella padre. Ma non in questo caso, perché l'integrità referenziale viene applicata a ogni riga nella tabella, ma non per i valori di riga. Quindi - perderai questo vantaggio - ed è uno dei fondamentali in relazione a DB
- Impossibile impostare i nomi degli attributi . Ciò significa che non puoi limitare correttamente il nome dell'attributo a livello di DB. Ad esempio, scriverai
"customer_name"come nome dell'attributo nel primo caso - e un altro sviluppatore lo dimenticherà e utilizzerà"name_of_customer". E... va bene, DB lo passerà e finirai con ore spese a eseguire il debug di questo caso.
Ricostruzione riga
Inoltre, la ricostruzione delle righe sarà terribile nel caso comune. Se hai, ad esempio, 5 attributi, saranno 5 self-table JOIN -S. Peccato per un caso così semplice - a prima vista -. Quindi non voglio nemmeno immaginare come manterrai 20 attributi.
Può essere giustificato?
Il mio punto è - no. In RDBMS ci sarà sempre un modo per evitarlo. È orribile. E se si intende utilizzare EAV, la scelta migliore potrebbe essere non relazionale banche dati.
