Discussion :

[Alexandre T]

Bonjour,

Je suis en train de modéliser pour une application un système de champs libres. Les utilisateurs du logiciel vont avoir régulièrement besoin de "nouvelles" colonnes dans la base de données, car le besoin est particulièrement évolutif. Il serait donc inapproprié qu'ils passent par le développement chaque fois qu'ils ont besoin de stocker de nouvelles informations. Par conséquent, je passe par un modèle de méta-données.
Il y a un cours d'ailleurs bien fait sur le site de sqlpro :
http://sqlpro.developpez.com/cours/m...n/metadonnees/

J'arrive à une solution très proche de celle présentée. L'indexation est plutôt simple à réaliser mais je me pose certaines questions sur ces index tout de même. Les données sont enregistrées au format châine de caractère : VARCHAR. Les index seront-ils correctement utiliser lors de conversions ? En effet, si je demande au système de me sélectionner un sous-ensemble de mes lignes par rapport à une valeur décimale, je vais devoir utiliser une fonction de conversion (CAST).
Exemple de requête concernée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT CRE_VALEUR 
  FROM T_DONNEES_DON DON
INNER JOIN TR_CARACTERISTIQUE_CAR CAR
   ON CAR.CAR_ID = DON.DON_ID
WHERE CAR.CAR_LIBELLE = 'Ma caractéristique numérique'
  AND CAST(DON.DON_VALEUR AS INTEGER) > 888

Est-ce que mon index sera performant ou serait-il plus optimal au niveau des accès de prévoir différentes colonnes dans la table T_DONNEES_DON ?
La table T_DONNEES_DON aurait alors plusieurs colonnes en quelquesorte :

TBL_ID
CAR_ID
CRE_LIGNE
CRE_VALEUR_NUMERIQUE
CRE_VALEUR_ALPHANUMERIQUE
CRE_VALEUR_TEMPOREL
CRE_VALEUR_INTERVAL

Sur chaque colonne CRE_VALEUR_*, je placerais un index. J'ai des doutes sur la rapidité d'accès des deux méthodes. Je vais monter les deux systèmes pour faire des tests, mais si quelqu'un a déjà modélisé un système en ce sens, je serais heureux d'avoir son retour.

Ci-dessous le modèle réalisé par sqlPRO :

[chrifo]

Bonjour,

J'ai eu un problème assez complexe de ce type (sous Oracle) il y a quelque temps, et je m'étais tourné vers la solution consistant à stocker dans des colonnes typées. Pour éviter les tables creuses, à chaque type correspondait une table.
Je m'étais tourné vers cette solution effectivement pour des questions de perf. ou plutôt de simplification d'optimisation, mais je trouve également cela plus propre, plus "cablé"; certain diront moins souple, car tu cables de fait les types utilisés ... à moins de laisser la porte ouverte en combinant les 2 écoles.

Dans l'attente de ton retour d'expérience ...
chrifo

[SQLpro]

Effectivement le typage étant faible l'idée de mettre des colonnes par type n'est pas mauvaise.
L'idée de mettre un héritage avec n tables (une par type) n'est pas mal, mais plus délicate car rajoute une couche de jointure. Si les données sont rarement modifiées (pas d'update), je pencherait pour tout dans la même table avec du VARCHAR. Sinon, tout dans des tables différentes avec du CHAR.

A +