Discussion :

[_Xavier_]

J'espère que je suis sur le bon endroit.

Je dois créer un entrepôt de données à partir du modèle EAV de mangento. J'ai quelques années d'expériences en BD mais je suis encore débutant en décisionnel. D'après les quelques lectures que j'ai effectuées sur le forum il serait mieux d'avoir une base de données différente de la base opérationnelle, spécialement pour la production. Pour l'instant je me contente de créer des vues pour obtenir des enregistrements "standards" à partir du nombre considérable de tables que l'on trouve dans un le modèle EAV, une sorte de base de données dans la base principale. Ce qui me pose un problème de performance lié au nombre considérable de jointures engendrées par les requêtes Sql. Pour avoir la liste des produits je fais des jointures sur toutes les tables contenant les différents champs de l'entité produit.

Je voudrais savoir :
1) s'il y'a des méthodes efficaces (langage d'interrogation par exemple) pour manipuler "normalement" (afficher des enregistrements complets) les données d'un modele EAV.

2) si passer du modele EAV au modele relationnel classique juste pour faire du reporting peut être un bon choix.

3) En dehors de sa stabilité ce que le modele EAV apporte comme plus par rapport au modele relationnel.

[TheLeadingEdge]

Bonsoir,
Attention je ne fait pas un réquisitoire contre mangento. C'est peut-être top.
Je répond juste à la question EAV vs SGBDr.

Ce qui me pose un problème de performance lié au nombre considérable de jointures engendrées par les requêtes Sql.

Tu as déjà identifié 1 pb.
Passée l'ivresse du premier moment ou on se croit le roi du monde parce qu'il n'y a plus rien a modéliser,
tu prends une grosse baffe quand tu t'aperçois que pour sortir la moindre donnée tu dois taper 4 pages de jointures.
C'est limite inutilisable coté développeur.

L'autre pb majeur est un pb de performance.
EAV est complètement incompatible avec un moteur relationnel. Au dela d'un certain volume les performances s'effondrent.
J'avais fait l'essai il y a qques années avec oracle 7 (oui je sais je suis joueur).
De mémoire le seuil était d'environ 200 colonnes et < à 10 000 lignes. (et c'est pas la peine de troller à propos d'Oracle, en tunant à mort on devait probablement faire 1 peu mieux, mais on faisait beaucoup mieux sans tuner avec un modèle classique.).
Du point de vue du moteur relationnel, il n'existe qu'une seule jointure.
L'optimiseur du moteur relationnel est incapable de calculer le moindre plan d'accés performant.
Ttes les données sont accédées séquentiellement. Même si elles sont en mémoire ça finit par être long.

passer du modele EAV au modele relationnel classique juste pour faire du reporting peut être un bon choix.

C'est mieux clairement, mais le modèle entités-relations n'est pas non plus le plus adapté. Il est optimisé pour des maj rapides sur des petits volumes.
Tu veux faire du reporting, donc potentiellement lire des gros volumes.
La solution est d'extraire tes données et de créer un star schéma dans un schema séparé (un datawarehouse quoi).

En dehors de sa stabilité ce que le modele EAV apporte comme plus par rapport au modele relationnel.

J'ai déjà répondu plus haut. Si tu as des petits volumes, c'est le top de l'évolutivité. Tu es complètement indépendant et tu fais évoluer ta base et donc ton appli comme tu veux, mais au delà d'un certain seuil c'est bon à jeter.

[_Xavier_]

Merci pour la clairevoyance

Quand j'ai vu la complexité des requêtes (pour quatres colones de la table produit j'ai fait quatre vues et des jointures externes) , avant même d'aller loin, je me suis dit qu'il doit y avoir un langage autre que le sql pour l'interrogation. .

Ce matin en fouillant un peu sur le net j'ai vu qu'un cache de la base de données suivant le modèle relationnel a été prévu par magento pour contourner le problème de la lenteur. La nature qui revient au galop.