Discussion :

[hphil]

Bonjour,

J'avais déjà formulé quelques questions concernant l'article sur la modélisation par métadonnées proposée en 2003 par SQLPro, ça date !

Ce type de modélisation a t-il un anglicisme particulier ?

Ça m'aiderait considérablement dans mes recherches sur Google pour cibler des ressources pertinentes et actualisées à ce sujet.

Si vous avez des liens, ça m'intéresse aussi

Pour exemple, "l'arborescence par représentation intervallaire" de SQLPro est plus connue sous l'anglicisme "nested tree" (arbre imbriqué) et on trouve des implémentations très intéressantes.

Merci de me répondre.

Cordialement,

Phil

[hphil]

Comme souvent, je réponds à mes questions.

En fait, il s'agit du "eav model" (entity-attribute-value model).

Ce modèle est utilisé par les premières versions de magento mais fait polémique puisque des lenteurs considérables sont constatées lors de la montée en charge !

Il semblerait donc que la team ait opté pour un système hybride, d'un coté en eav model pour la flexibilité de manipulation et de l'autre le modèle relationnel classique utilisé sous forme de cache pour la sélection et les tris.

Bref, je suis bien embêté puisque j'avais opté pour l'eav model, je vais donc devoir revoir ma copie

[iberserk]

Nous l'utilisons pour un site d'ebusiness entièrement paramétrable par le client pour la gestion des caractéristiques des articles.

Nous ne rencontrons aucun problème de performance...

La seule différence est que nos colonnes sont typées (4 colonnes:INT,DATETIME,DECIMAL,VARCHAR) au lieu d'utiliser une seule colonne VARCHAR...

il y même une vieille version du site vraiment pas optimisée (la table des caractéristique fais 12 Millions...)

Nous utilisons SQL SERVER 2005

[hphil]

Bonjour,

@iberserk merci pour votre réponse.

J'avais en effet envisagé de créer plusieurs tables d'entités "fortes" avec des tables de stockage de valeurs en fonction du typage de données comme vous le suggérez.

Pour limiter la redondance de données, j'avais pensé créer une table de type INT pour stocker les clés de certaines valeurs prédéfinies de caractéristiques contenues dans une autre nouvelle table.

Je ne sais pas si c'est une bonne idée, puisque l'on sort du modèle d'utilisation classique d'un tel modèle. En terme de performance des requêtes SQL, c'est peut-être pénalisant...

Cordialement,

Phil