Comment combler les lacunes dans les rapports de base de données EAV?

StackOverflow https://stackoverflow.com/questions/2523741

Question

Les lacunes majeures avec des conceptions de base de données entité-attribut-valeur dans SQL semblent tous être liés à être en mesure d'interroger et de faire rapport sur les données de manière efficace et rapide. La plupart des informations que je lis sur le sujet mettent en garde contre la mise en œuvre EAV en raison de ces problèmes et les points communs des requêtes / rapports pour presque toutes les applications.

Je suis en train de concevoir un système où les champs pour l'une des entités ne sont pas connus à la conception / compilation et sont définis par l'utilisateur final du système. EAV semble être un bon moyen pour cette exigence, mais en raison des problèmes que j'ai lu, je suis hésitant à mettre en œuvre comme il y a aussi des exigences en matière de rapports assez lourds pour ce système aussi bien. I pense Je suis venu avec une façon de contourner cela mais je voudrais poser la question à la communauté SO.

Étant donné que la base de données normalisée typique (OLTP) est toujours pas toujours la meilleure option pour les rapports en cours d'exécution, une bonne pratique semble avoir une base de données « reporting » (OLAP) où les données de la base de données normalisée est copié, indexé largement, et peut-être dénormalisé pour effectuer des requêtes plus facile. la même idée pourrait être utilisée pour contourner les lacunes d'une conception EAV?

Le principal inconvénient que je vois sont la complexité accrue de transfert des données de la base de données EAV à des rapports que vous pouvez finir par avoir à modifier les tables de la base de données de rapports en tant que nouveaux champs sont définis dans la base de données EAV. Mais cela est impossible à peine et semble être un compromis acceptable pour la flexibilité accrue donnée par la conception EAV. Cet inconvénient existe aussi si j'utilise un magasin de données non-SQL (à savoir CouchDB ou similaire) pour le stockage principal des données puisque tous les outils de reporting standards attendent un backend SQL pour interroger contre.

Est-ce que les problèmes avec les systèmes EAV vont surtout loin si vous avez une base de données de rapports séparés pour effectuer des requêtes?

EDIT: Merci pour les commentaires à ce jour. L'une des choses importantes sur le système que je travaille sur ce que je suis vraiment parler que sur l'utilisation de EAV pour l'une des entités, pas tout dans le système.

L'essentiel ensemble du système est d'être en mesure de tirer des données provenant de sources multiples disparates qui ne sont pas connus à l'avance et crunch les données pour trouver des données « les plus connues » au sujet d'une entité particulière. Ainsi, chaque « champ » je traite est à plusieurs valeurs et je suis également tenu de suivre l'histoire pour chacun. La conception normalisée pour cela finit par être 1 table par champ qui rend ce genre de requêtes douloureuse de toute façon.

Voici les schémas de table et des échantillons de données que je regarde (évidemment changé de ce que je travaille, mais je pense qu'il illustre bien le point):

Tables EAV 

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_Value
-------------------------------------------------------------------
- PersonId - Source - Field       - Value         - EffectiveDate -
-------------------------------------------------------------------
-      123 -    CIA - HomeAddress - 123 Cherry Ln -    2010-03-26 -
-      123 -    DMV - HomeAddress - 561 Stoney Rd -    2010-02-15 -
-      123 -    FBI - HomeAddress - 676 Lancas Dr -    2010-03-01 -
-------------------------------------------------------------------

Tableau de rapports 

Person_Denormalized
----------------------------------------------------------------------------------------
-  Id - Name      - HomeAddress   - HomeAddress_Confidence - HomeAddress_EffectiveDate - 
----------------------------------------------------------------------------------------
- 123 - Joe Smith - 123 Cherry Ln -                  0.713 -                2010-03-26 -
----------------------------------------------------------------------------------------

Normalisée design 

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_HomeAddress
------------------------------------------------------
- PersonId - Source - Value         - Effective Date - 
------------------------------------------------------
-      123 -    CIA - 123 Cherry Ln -     2010-03-26 -
-      123 -    DMV - 561 Stoney Rd -     2010-02-15 -
-      123 -    FBI - 676 Lancas Dr -     2010-03-01 -
------------------------------------------------------

La « confiance » champ est généré en utilisant la logique ici qui ne peut être exprimé facilement (le cas échéant) en utilisant SQL si mon opération la plus courante en plus d'insérer de nouvelles valeurs seront en tirant toutes les données concernant une personne pour tous les champs afin que je puisse générer la record pour le tableau de déclaration. Ceci est en fait plus facile dans le modèle EAV que je peux faire une seule requête. Dans la conception normalisée, je finis par avoir à faire une requête par champ pour éviter un produit cartésien massif de les rejoindre tous ensemble.

Était-ce utile?

La solution

Réponse courte -. Oui, une base de données de rapports est une approche raisonnable pour résoudre les problèmes de rapports à partir d'un modèle de données EAV

J'ai passé plusieurs années à travailler avec une solution de gestion de l'information qui a permis aux utilisateurs finaux une totale liberté de définir leur propre modèle de données, à la fois le schéma et les données stockées à l'aide d'un modèle EAV. Fait intéressant, ce produit a fourni des objets méta-schéma utilisé pour répondre aux exigences de rapport (par exemple des graphiques pour fournir une navigation objet, vue d'effectuer la projection, etc.). Cela signifie que l'utilisateur final était libre de définir des requêtes en utilisant les mêmes termes et concepts qu'ils avaient utilisés pour construire le modèle de données en première instance. L'acte de l'information était essentiellement de calculer l'ensemble des données en parcourant ces définitions, et remettre le résultat sur un outil de rédaction du rapport traditionnel comme si elle agissait de données relationnelles.

L'un des points forts de cette approche est que le même mécanisme qui était déjà en place pour transformer le modèle EAV à quelque chose que l'utilisateur pourrait travailler avec peut être réutilisée et appliquée à la fonction de reporting.

Autres conseils

  

Dans ce schéma, tout d'abord, nous arrivons avec un système qui permet aux utilisateurs de stocker tout type de données que ce soit, quelle que soit sa structure, et quel que soit l'avenir l'utilisation prévue. Puis, quand il est temps d'obtenir les rapports sur, nous devons comprendre ce que nous avons, et comment cela se rapporte à ce que nous avons besoin.

Puisque vous attribuez clairement la nature du problème à « être dans ce schéma », il me semble vraiment comme si le problème avec EAV vraiment est en raison de EAV en tant que tel.

En fait, venez à penser: « un système qui permet aux utilisateurs de stocker tout type de données que ce soit » est l'équivalent d'un système qui permet aux utilisateurs de définir simplement leurs relvars. Mais quelle partie de ce système permet aux utilisateurs de définir des contraintes sur chaque attribut? Oops, la foule EAV semble avoir manqué un aspect pas si peu d'importance de la gestion des données, il semble ...

Le problème avec EAV est pas dû à EAV en tant que tel. Il est dû à la conception et la construction d'une base de données sans comprendre ce que les exigences de données sont vraiment, et quelle est la structure logique des données doivent avoir pour répondre à ces exigences. EAV, et tout autre système qui permet aux utilisateurs de concevoir leurs propres données, tourne cela sur sa tête.

Dans ce schéma, tout d'abord, nous arrivons avec un système qui permet aux utilisateurs de stocker tout type de données que ce soit, quelle que soit sa structure, et quel que soit l'avenir l'utilisation prévue. Puis, quand il est temps d'obtenir les rapports sur, nous devons comprendre ce que nous avons, et comment cela se rapporte à ce que nous avons besoin.

Bonne chance.

Il n'y a pas de problème avec EAV je passe une assez grande quantité de temps de l'interrogation des bases de données MASSIVES EAV. Toute personne qui dit des rapports de EAV est difficile, voire impossible, de 1 a 2 problèmes, que ce soit ils ont un système EAV très mal conçus ou ils ne comprennent pas comment interroger d'un. obtenir de belles données à partir d'un rapport en mesure DB EAV est assez facile une fois que vous l'avez fait à quelques reprises. Il n'y a pas besoin d'une base de données de rapports ou quelque chose de spécial, juste quelques bonnes questions.

Si vous construisez un EAV DB passer beaucoup de temps à sa conception, la conception sera faire ou casser votre demande et ce sera un cauchemar d'essayer de corriger ou faire face à un mal conçu.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top