No, questo è un cattivo design per un database relazionale. Questo è un esempio di Entity-Attribute-Value design. È flessibile, ma infrange la maggior parte delle regole di cosa significa essere un database relazionale.
Prima di entrare nel design EAV come soluzione per un database flessibile, leggi questa storia:Bad CaRMa .
Più specificamente, alcuni dei problemi con EAV includono:
- Non sai quali attributi esistono per un dato ID_NUM senza eseguirne una query.
- Non puoi rendere obbligatorio alcun attributo, l'equivalente di NOT NULL.
- Non puoi utilizzare i vincoli del database.
- Non puoi usare i tipi di dati SQL; il
valuela colonna deve essere un VARCHAR lungo. - In particolare in MySQL, ogni VARCHAR è archiviato nella propria pagina di dati, quindi è molto dispendioso.
Le query sono anche incredibilmente complesse quando si utilizza il design EAV. Magento, una piattaforma di e-commerce open source, utilizza ampiamente EAV e molti utenti affermano che è molto lento e difficile interrogare se hai bisogno di rapporti personalizzati.
Per essere relazionale, dovresti memorizzare ogni diverso attributo nella propria colonna, con il proprio nome e un tipo di dati appropriato.
Ho scritto di più su EAV nella mia presentazione Practical Object-Oriented Modelli in SQL e nel mio post sul blog EAV FAIL e nel mio libro, SQL Antipatterns:evitare le insidie della programmazione di database .
