Alternatives à Entity-attribut-Value (EAV)?
notre base de données est conçue sur la base du modèle EAV (Entity-attribut-Value). Ceux qui ont travaillé avec des modèles EAV savent toutes les conneries qui viennent avec dans le but de la flexibilité.
j'ai demandé à mon client les raisons pour lesquelles l'utilisation du modèle EAV (flexibilité), et leur réponse a été: leurs entités changent avec le temps. Donc, aujourd'hui, ils peuvent avoir une table avec un peu d'attributs, mais en un mois de temps, quelques nouveaux attributs peuvent être ajoutés, ou un attribut existant peut être renommé. Ils doivent produire des rapports pour revenir à n'importe quelle étape dans le temps et interroger les données en fonction de la forme des entités à cette étape.
je comprends que ce n'est pas faisable avec un modèle relationnel conventionnel, mais je considère personnellement EAV comme anti-modèle. Existe-t-il d'autres modèles qui nous permettent de saisir la dimension temporelle dans les changements apportés aux entités et aux instances?
santé, Mosh
4 réponses
il y a une différence entre un VAE fait fidèlement ou mal; 5NF fait par des gens qualifiés ou par ceux qui sont ignorants.
la sixième forme normale est la forme normale irréductible (aucune autre Normalisation n'est possible). Il élimine beaucoup des problèmes qui sont communs, tels que le problème Null, et fournit la méthode ultime d'identification des valeurs manquantes. C'est le NF académique et techniquement robuste. Il n'y a pas de produits pour le soutenir, et il n'est pas utiliser. Pour être mis en œuvre de façon appropriée et cohérente, il faut un catalogue de métadonnées. Bien sûr, le SQL requis pour le naviguer devient encore plus encombrant (SQL étant déjà encombrant re jointures), mais cela est facilement surmonté en automatisant la production de SQL à partir des métadonnées.
EAV est un ensemble partiel ou un sous-ensemble de 6NF. Le problème est que, généralement, cela est fait dans un but précis (permettre l'ajout de colonnes sans avoir à faire des changements DDL), et par personnes qui ne connaissent pas le 6NF et qui ne mettent pas en œuvre les métadonnées. Le point est, 6NF et EAV que les principes et les concepts offrent des avantages substantiels, et la performance augmente; mais généralement, il n'est pas mis en œuvre correctement, et les avantages ne sont pas réalisés. Un bon nombre de mises en œuvre de L'EAV sont des désastres, non pas parce que L'EAV est mauvais, mais parce que la mise en œuvre est médiocre.
par exemple. Certains pensent que L'SQL nécessaire pour construire les lignes 3NF à partir de la base de données 6NF/EAV est complexe: non, c'est lourd, mais pas complexe. Plus important encore, une vue SQL ordinaire peut être fournie, de sorte que tous les utilisateurs et outils de rapport ne voient que la vue 3NF droite, et les problèmes 6NF/EAV sont transparents pour eux. Enfin, le SQL requis peut être automatisé, de sorte que le coût de la main-d'œuvre que beaucoup de gens endurent est tout à fait inutile.
ainsi la réponse est vraiment, sixième forme normale, étant le père de L'EAV, et une forme plus pure, est le remplacement pour elle. La mise en garde est, assurez-vous qu'il est fait correctement. J'ai un grand 6NF db, et il ne souffre aucun des problèmes que les gens postent sur, il fonctionne magnifiquement, le client est très heureux (aucun autre travail est un signe de la satisfaction fonctionnelle complète).
j'ai déjà posté une très détaillée en réponse à une autre question qui s'applique à votre question, ce qui pourrait vous intéresser.
quel que soit le type de modèle relationnel que vous utilisez, le suivi des changements de nom de champ nécessite un grand nombre de métadonnées dont vous devez tenir compte dans les journaux de transactions ou les tables de vérification. Malheureusement, interroger l'un ou l'autre de ces états à une date donnée est très compliqué. Si votre client n'a besoin que de l'État à une date précise, c'est-à-dire l'état entier, pas seulement en ce qui concerne les changements de nom, vous pouvez dupliquer la base de données et retourner le journal des transactions à la temps particulier requis et lancez vos requêtes sur la nouvelle instance. Si des entités ajoutées après la date spécifiée doivent apparaître dans la requête avec les anciens noms de champ, cependant, vous avez un très gros problème d'ingénierie devant vous. Dans ce cas, compte tenu de l'information que vous avez fournie dans votre question, je suggérerais de négocier des solutions de rechange avec le client ou d'obtenir plus d'information sur l'utilisation des rapports pour trouver des solutions de rechange.
vous pourriez passer à un document basé sur datastore, mais cela ne résoudrait toujours pas le problème dans le second cas. Désolé, ce n'est pas vraiment une réponse, mais après avoir traversé des situations similaires, le client a probablement besoin d'une solution de rapport plus réaliste ou un certain nombre d'autres investisseurs disposés à front le capital pour l'ingénierie.
lorsque ce problème est apparu pour nous, nous avons maintenu le schéma de base de données constant et avons mis en place une usine de cartographie des entités basée sur un horodatage. En fin de compte, le client les besoins changeaient continuellement (sur une base hebdomadaire à mensuelle) quant à la façon dont les champs agrégés étaient calculés et n'étaient jamais entièrement satisfaits.
pour ajouter aux réponses de @NickLarsen et @PerformanceDBA
si vous avez besoin de suivre les changements historiques à des choses comme le nom de champ, vous pouvez vouloir regarder dans quelque chose comme lentement changer les Dimensions . Il me semble que vous utilisez L'EAV pour modéliser des modèles dimensionnels dynamiques (probablement des listes de recherche).
Le plus simple (et probablement moins efficace moyen d'y parvenir serait d'inclure un "de" champ date sur les tables EAV, et chaque fois qu'un changement se produit, insérez un nouvel enregistrement (au lieu de mettre à jour un enregistrement existant) avec la date courante. Cela signifie que vous devez modifier vos requêtes pour toujours inclure ou rechercher une date "as of", OU "deafult" à " now " si aucune donnée n'est fournie. Votre entité de base qui se joint aux objets EAV devra alors interroger "top 1" à partir de la table EAV où la date "as of" est inférieure ou égale à la date "last updated" de la ligne, ordonnée par "as of" descendant. Pire des cas scénario, si vous devez suivre le changement le plus récent à une ligne donnée où le nom (stocké dans la table 'attribut') et la valeur ont changé, vous enchaînerez cette logique à la table de valeur en utilisant 'last modified' de la ligne pour trouver la valeur appropriée pour cette date particulière.
cela a évidemment le potentiel de générer de grandes quantités de données s'il y a beaucoup de changements. C'est pourquoi cette approche est appelée "lentement" en constante évolution. Il est destiné dimensions des valeurs qui peuvent changer, mais pas très souvent. Pour aider avec la performance de requête, les index sur les champs "as of" et "last modified" devraient aider.
créer une nouvelle description de tableau pour chaque version de description D'entité et une table supplémentaire qui vous dit quelle table est quelle version. Le système d'interrogation devrait également être mis à jour.
je pense que créer un script qui génère, des tables et des requêtes est votre meilleur plan.