Discussion :

[vinzzzz]

Bonjour,

Je souhaite dans mon modèle de DB, donner la possibilité à un utilisateur d'associer à chaque objet référencé dans une table Object, les propriétés de son choix et ce de manière dynamique. Pour ce faire, je compte utiliser le modèle suivant:

Code :

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

1
2
3
4
5
6
7
8
Propriété
---prop_id
---prop_name
 
PropriétéValue
---pval_prop_id
---pval_object_id
---pval_value

La colonne pval_value serait de type VARCHAR, et je ferai la conversion de manière dynamique lorsqu'il s'agira, par exemple, de filtrer les données sur une propriété de type numérique.

J'hésite tout de même à créer deux tables différentes pour PropriétéValue: une dédiée aux propriétés de type chaines de caractères, et l'autre aux propriétés numérique...

Quelle solution vous semble la plus adaptée en terme de flexibilité, de performances et de design ? Je précise que cette table sera suceptible de contenir au moins plusieurs dizaines de millions de lignes...

Merci d'avance de vos conseils

[soazig]

Bonjour,
J'ai l'impression que la lecture de cet article t'éclairera.
http://sqlpro.developpez.com/cours/m...n/metadonnees/
Ca a l'air de correspondre à ta problématique, et ça a l'air de correspondre à une problématique que je vais avoir à résoudre.
Donc je vais le finir, pour l'instant j'ai survolé.

Cordialement
Soazig forterre

[vinzzzz]

Merci de ta réponse

Comme tu as surement pu le constater mon modèle s'approche de celui présenté dans cet article: je représente déjà mes propriétés de manière relativement générique.

La question est de savoir est-ce que ca vaut le coup de faire deux tables différentes pour stocker les valeurs de propriétés, sachant que je n'ai à faire la différence qu'entre les propriétés numériques et de type chaines de caractère (pas d'énumérations etc...)...

Mon soucis concerne surtout les performances, puisqu'avec une table générique telle que présentée dans mon post initial, il faut "caster" les données numériques pour pouvoir faire des opérations dessus.

Dans l'article présenté, le type est associé à chaque valeur, mais il y a toujours la nécessité de "caster" les données...

Sur des centaines de millions de lignes, je me demande ce que ca peux donner...

[SQLpro]

étant l'auteur je vais vous répondre :
1) cela dépend de votre SGBDR. SI comme SQL Server il comporte un type polymorphe du genre SQL_variant, alors les perf seront correcte dans une seule et même colonne.
2) si les données littérales sont petites cela veut le coup de ne faire qu'une seule table
3) si les données littérale et numériques sont conjointement recherchées, alors il est intéressant de séparer en deux tables.

A +

[vinzzzz]

Merci de votre réponse.

1. J'essai de faire le plus "standard" possible dans la (re)définition de ma base, donc je privilégie dans la mesure du possible les solutions non-spécifiques d'un SGBD, qui dans mon cas se trouve être mysql (et dans l'avenir postgresql j'espère).

2. J'ai limité la taille des données texte à 50 caractères.

3. Les données à la fois littérales et numériques sont suceptibles d'être utilisées pour filtrer les données... D'où mon idée de séparer les deux pour éviter les "cast" hazardeux...

Je pense que je vais partir sur la gestion de deux tables...

Merci de votre aide!