Précédent   Forum des professionnels en informatique > Bases de données > Langage SQL
Langage SQL Forum d'entraide sur le langage SQL et sur les questions liées à la conception de schéma (DDL). Cours SQL
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 13/04/2011, 13h15   #1
Candidat au titre de Membre du Club
 
Inscription : mars 2005
Messages : 30
Détails du profil
Informations personnelles :
Âge : 35

Informations forums :
Inscription : mars 2005
Messages : 30
Points : 12
Points : 12
Par défaut Modélisation par métadonnées

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 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 13/04/2011, 18h42   #2
Candidat au titre de Membre du Club
 
Inscription : mars 2005
Messages : 30
Détails du profil
Informations personnelles :
Âge : 35

Informations forums :
Inscription : mars 2005
Messages : 30
Points : 12
Points : 12
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
hphil est déconnecté   Envoyer un message privé Réponse avec citation 10
Vieux 16/04/2011, 09h36   #3
Membre Expert
 
Avatar de iberserk
 
Homme Bruno IGNACE
Architecte de base de données
Inscription : novembre 2004
Messages : 1 299
Détails du profil
Informations personnelles :
Nom : Homme Bruno IGNACE
Âge : 30
Localisation : France, Gironde (Aquitaine)

Informations professionnelles :
Activité : Architecte de base de données
Secteur : High Tech - Éditeur de logiciels

Informations forums :
Inscription : novembre 2004
Messages : 1 299
Points : 2 282
Points : 2 282
Envoyer un message via MSN à 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
__________________
Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
iberserk est déconnecté   Envoyer un message privé Réponse avec citation 10
Vieux 17/04/2011, 13h57   #4
Candidat au titre de Membre du Club
 
Inscription : mars 2005
Messages : 30
Détails du profil
Informations personnelles :
Âge : 35

Informations forums :
Inscription : mars 2005
Messages : 30
Points : 12
Points : 12
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
hphil est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 02h26.


 
 
 
 
Partenaires

Hébergement Web