Bien que minimaliste comme indiqué, la table attributaire de Model2 introduit le concept de méta-données dans le mélange, avec tout le bien qui en découle. Le Model2 présente d'autres avantages, par exemple les gains de performances associé à une taille de ligne plus petite (de la table des valeurs), mais j'aimerais me concentrer sur le concept de métadonnées.
Même tel quel La table d'attributs de Model2 constitue un référentiel de tous les attributs valides (avec model1, il faudrait exécuter une sorte de requête agrégée pour obtenir une telle liste). Aussi, et tel quel , le référentiel est suffisant pour introduire des contraintes de clé étrangère pour aider à maintenir l'intégrité de l'ensemble de données (avec le modèle 1, il faudrait des formes externes de validation des valeurs stockées dans la colonne d'attribut.
Avec quelques ajouts simples, la table attributaire peut devenir un référentiel polyvalent qui peut être utilisé à diverses fins. Par exemple, le tableau peut inclure certains des éléments suivants
- des informations telles que le nom convivial de chaque attribut
- quelques drapeaux indiquant le type de champ (numérique vs. chaîne vs. date etc.), pour une manipulation/traitement différencié
- la table de valeurs particulière dans laquelle l'attribut sous-jacent est stocké (le modèle n'affiche qu'une seule table, mais l'optimisation/la mise à l'échelle invite parfois à diviser les tables)
- le fait que l'attribut puisse être stocké dans sa propre colonne dans la table "Valeur" (encore une forme d'optimisation, obtenant essentiellement le meilleur des deux mondes :la flexibilité du schéma du modèle EAV mais la performance du modèle traditionnel modèle relationnel pour les attributs les plus utilisés et/ou les plus communs à toutes les entités.
- la possibilité de renommer les attributs, sans perturber la table principale. Modifications au niveau des métadonnées uniquement.
- diverses sémantiques orientées application. Par exemple, des indicateurs indiquant qu'un attribut particulier devrait être proposé comme l'un des champs de recherche de base ou avancés.
En un mot, la table attributaire devient une ressource qui permet à l'application d'être véritablement pilotée par les données (ou plus précisément, meta piloté par les données). En effet, vous pouvez également aimer une table d'entités, c'est-à-dire une table où sont rassemblées les métadonnées relatives aux différents types d'entités :quels sont les différents types d'entités, quels attributs sont autorisés pour quel type d'entité, etc.
Maintenant... faites attention au commentaire de zerkms , sous la question elle-même. Malgré tous ses avantages, le modèle EAV comporte également son lot d'inconvénients et de défis, comme l'indique la complexité des requêtes qui vient à l'esprit, ainsi que les problèmes de performances. Ces préoccupations ne doivent cependant pas disqualifier, a priori, l'EAV :il existe de nombreux cas d'utilisation où l'EAV est une meilleure approche. P>
