Fiche technique d'un produit

**un_passant** · 01/11/2006, 16h00

Bonjour,

Je suis en train de concevoir une base de données pour MySQL et la je suis devant un problème.
J'ai un produit dans une catégorie et j'aimerai lui associer une fiche technique. Mais le probleme c'est qu'en fonction de la catégorie la fiche technique sera différente.

Exemple :
Produit1 dans Cat1
Taille: petit, grand
Poid: lourd, leger, moyen
Couleur: rouge, bleu, vert...
Produit2 dans Cat2
Vitesse: rapide, lente
Couleur: rouge, bleu, vert...

J'ai donc deux tables, produit et categorie avec chacun leurs clef primaire. Comment je peux gerer ma fiche produit sans que cela soit une usine a gaz?

ps: je suis debutant

**ego** · 04/11/2006, 20h37

Ton problèmen'st-il pas simplement que tu as plusieurs types de produits,tut simplement. Par exemple :

Légumes, Vêtements, Chaussures,...

Si c'est cela et si ton truc ne doit pas évoluer souvent, tu peux peut être conceptuellement créer autant de "classes" que de type de produit avec éventuellement un classe de base à toutes ces classes qui contiendrait, si cela est nécessaire, des caractéristiques communes à tous les types de produits.
Dans ta base cela donnera une table par classe (donc par type de produit), avec éventuellement un table pour la classe de base (si elle existe). Un produit sera donc matérialisé par une ligne dans la table appropriée et une ligne dans la table de base (toujours si elle existe).
Si tu veux un truc plus évolutif, il va falloir faire un schéma de base plus "méta". On peut en discuter si c'est cela qui te semble plus approprié.

**un_passant** · 05/11/2006, 18h39

J'ai aussi penser à la premiere solution, mais cela me semble trop "usine a gaz" si il y a beaucoup de catégorie et il aura beaucoup.

Je prend pour exemple un comparateur de prix, voila deux produits dans deux categories differentes :
http://prixmateriel.com/processeurs_...ail_16780.html
http://prixmateriel.com/cartesmeres_...ail_36531.html
Les deux fiches techniques n'ont rien en commun, il faut supposer aussi que je peux rajouter une propriéter dans la fiche quand j'en ai besoin. Je peux aussi (pour l'exemple) avec besoin de trouver toutes les cartes mères avec un socket LGA775...

Voici les deux tables que j'ai pour le moment reduites au minimum :
Categorie(id, nom)
Produit(id, nom, idCategorie)

En utilisant la première solution je devrai creer énormement de tables :s .

C'est un vrai casse tête, enfin pour moi. Merci pour ton aide

.

**ego** · 05/11/2006, 20h23

C'est donc la seconde solution qu'il te faut.
Il faut créer un schéma de base de données qui va permettre de dynamiquement définir un type de produit.
Un première partie, le méta-modèle te permet de découvrir tes types de produit.
La seconde partie, un modèle générique, te permet de stocker tout type de produit sans modification de schéma. Dan cette seconde partie, à toi de définir tous les types de propriété (int, string, float, date,...). C'est cette partie qui elle sera fixe et devra prévoir tous les cas.
Je n'ai pas abordé le cas de produit composites ici.

**un_passant** · 05/11/2006, 20h58

J'ai du mal à comprendre.
Par rapport à mon exemple du comparateur de prix, un "TypeProduit" est un Processeur, le "TypePropriete" une Fréquence ou Vitesse du Bus.
Le "Produit" est Athlon 64 3000+.
C'est bien ca?
Mais pour le reste je ne vois pas à quoi cela peut correspondre.

**ego** · 05/11/2006, 21h42

Oui, tu as compris.
Le reste comme tu dis, ce doit être les classes ProprieteString, etc... ?
Si c'est cela, ces classes et donc les tables qui vont en découler vont te permettre de stocker effectivement un produit.

Prenons le cas de ton Athlon64.
Table Produit
id=1, nom = Athlon64

Table ProprieteTypeFloat
id = 1, nom = frequence, valeur = 3.3, fkproduit = 1
id = 2, nom=Vitesse Bus, valeur = 100.0, fkproduit = 1

**un_passant** · 05/11/2006, 22h12

Oui c'etais bien ca, maintenant je vois pour les ProprieteTypes, mais pas pour Propriete.

**ego** · 06/11/2006, 18h49

Mon modèle est un peu "faux". J'ai oublié de mettre uniquement une association entre Produit et Propriete. Inutile de mettre les associations vers les classes dérivées de Propriete. La classe Propriété est là uniquement comme classe de base à toutes les classes ProprieteTypeXXX dans la mesure où toutes les propriétés possèdent au moins un nom et éventuellement d'autres attributs si tu en as besoin.