Discussion :

[Diogon]

Salut à tous,

J'ignore si je suis dans le bon forum. Techniquement je travaille sous MS SQL-Server mais dans la pratique mon problème n'est pas spécifique à un type de SGBD.

Petit litige entre un de mes amis et moi concernant la meilleure manière de mettre en place un système de caractéristiques dynamique.

Je m'explique: nous essayons de mettre en place une sorte de webshop (ou plutôt une banque de données de produits). Nous présentons différents produits en fonction de leur caractéristiques cependant nous nous trouvons face à un problème: comment stocker ces caractéristiques de façon dynamique au sein d'une base de données? sachant qu'une caractéristique peut-être au format numérique (la largeur par exemple), string (la couleur) ou autre. D'autant qu'il faut pouvoir comparer les données d'un même type (il faudrait que je puisse trier les produits en fonction de leur prix, de leur couleur, etc.)

Mon ami est partisan d'utiliser une table au format:

•Id (Identifiant de la valeur)
•XId_caract (Clé étrangère vers la caractéristique en question)
•Type (type de la valeur permettant de savoir dans quelle colonne chercher la valeur)
•Valeur_Entière (contient la valeur si celle-ci est int et null sinon)
•Valeur_Decimale (contient la valeur si celle-ci est decimal et null sinon)
•Valeur_String (contient la valeur si celle-ci est varchar et null sinon)
•Valeur_Date (contient la valeur si celle-ci est datetime et null sinon)
•Valeur_Duree (contient la valeur si celle-ci est timestamp et null sinon)

Il propose en alternative de remplacer les Valeur_[Type] par une clé étrangère qui renvoie vers des tables différentes selon le type (pour éviter de perdre de l'espace) néanmoins j'y suis globalement opposé en raison de la perte d'intégrité référentielle que cela génererait.

Pour ma part, je suis plutôt partisan d'un stockage sous cette forme:

•Id (Identifiant de la valeur)
•XId_caract (Clé étrangère vers la caractéristique en question)
•Type (type de la valeur permettant de savoir le type de la valeur)
•Valeur (contient la valeur sous la forme d'un varchar formaté de manière à permettre la comparaison de type similaires)
Ma méthode souffre bien entendu de défauts elle aussi (entre autre, le fait de placer les données dans un format personnalisé empêche leur accès par des personnes extérieures).

N'arrivant pas à nous décider, je me permet de faire appel à l'équipe pour vous demander quelle est selon vous la meilleure des deux méthode ou, encore mieux, si vous en avez une qui soit meilleure encore.

Je précise que le programme lui-même travaille en orienté objet ce qui restreint partiellement les possibilités.

Un tout grand merci à tous.

[Donpi]

Je vote pour votre solution pour les même raisons que vous.

Cependant avez vous évalué les base de données Objet ?
Je pense que ça réglerait votre litige dans l'oeuf.

A+

[Diogon]

C'est déjà un avis ^^

Pour ce qui est des bases de données objet, bien que je pense que cela corresponde mieux à nos besoins, cela n'est malheureusement pas une option. Nous travaillons en effet dans un envirronnement fermé qui ne nous laisse pas vraiment le choix de nos outils.

[Donpi]

C'est déjà un avis ^^

Pour ce qui est des bases de données objet, bien que je pense que cela corresponde mieux à nos besoins, cela n'est malheureusement pas une option. Nous travaillons en effet dans un envirronnement fermé qui ne nous laisse pas vraiment le choix de nos outils.

Ouais j'en connais un rayon.. je travaille en windev... béééee

Bonne chance pour la suite

[aieeeuuuuu]

Bonjour,

Avoir le modèle complet, ou au moins les tables tournant autour de votre problématique permettrait de mieux répondre à votre question.

Par exemple, vous semblez avoir une table des caractèristiques. :

XId_caract (Clé étrangère vers la caractéristique en question)

Ce qui est une bonne chose. Mais dès lors, pourquoi ne pas y mettre le type ?

J'opterais également pour une seule colonne quel que soit le type.
en complément, un peu de lecture : http://sqlpro.developpez.com/cours/m...n/metadonnees/

[StringBuilder]

Et sinon, pourquoi ne pas prendre la solution de votre amis à l'envers ?

Caractéristique
--------------
Id
Nom (Hauteur, Largeur, Couleur, Poids à vide, Charge utile, etc.)
Type (Dimension, Couleur, Masse)

CaractéristiqueProduit
--------------
Id
Id_Produit

Dimension
---------------
Id_caracterisqueproduit
Valeur

Masse
----------------
Id_caracterisqueproduit
Valeur

Couleur
----------------
Id_caracterisqueproduit
Valeur

[...]

Ainsi :
- Aucune perte d'intégrité référentielle
- Plutôt que d'avoir des types "simples" (nombre, date, texte) je préconise des types "complexes" (largeur ou au moins dimension, couleur, poids, etc.)

En effet, cela vous permettra de comparer des caractéristiques entre produits hétérogènes (tous les produits qui ont une "largeur" de X cm), ou tous les produits bleus.

Cela permet aussi de :
- Réutiliser les mêmes tables de correspondance (énumération des couleurs, etc.)
- Réutiliser dans votre code les mêmes objets pour le rendu des caractéristiques similaires (un sélecteur de couleur sera le même quel que soit le produit, du moment qu'il s'agit d'une couleur)

L'utilisation de valeurs textuelles, je suis contre. Impossible de faire de comparaisons (101 > 2), problèmes de transtypage ("100 cm" n'est pas un nombre), etc.
Ou alors à ce moment, vous stockez vos caractéristiques dans un type XML, et tant pis pour les performances, au moins vous avez quelque chose de propre et utilisable. Ce sera de toute façon pas pire que de faire des cast dans tous les sens.