Non, c'est une mauvaise conception pour une base de données relationnelle. Ceci est un exemple de Entity-Attribute-Value motif. C'est flexible, mais cela enfreint la plupart des règles de ce que signifie être une base de données relationnelle.
Avant de vous plonger dans la conception EAV en tant que solution pour une base de données flexible, lisez cette histoire :Mauvaise CaRMa .
Plus précisément, certains des problèmes avec EAV incluent :
- Vous ne savez pas quels attributs existent pour un ID_NUM donné sans les interroger.
- Vous ne pouvez rendre aucun attribut obligatoire, l'équivalent de NOT NULL.
- Vous ne pouvez pas utiliser les contraintes de base de données.
- Vous ne pouvez pas utiliser les types de données SQL ; la
valuecolonne doit être un long VARCHAR. - En particulier dans MySQL, chaque VARCHAR est stocké sur sa propre page de données, c'est donc très inutile.
Les requêtes sont également incroyablement complexes lorsque vous utilisez la conception EAV. Magento, une plate-forme de commerce électronique open source, utilise largement EAV, et de nombreux utilisateurs disent qu'il est très lent et difficile de demander si vous avez besoin de rapports personnalisés.
Pour être relationnel, vous devez stocker chaque attribut différent dans sa propre colonne, avec son propre nom et un type de données approprié.
J'ai écrit plus sur EAV dans ma présentation Practical Object-Oriented Modèles en SQL et dans mon article de blog EAV FAIL , et dans mon livre, Antipatterns SQL :Éviter les pièges de la programmation de base de données .
