salut,
ce que Mazarini indique c'est la relation entre les catégories (donc fleurs => rose => rose rouge) la catégorie de "base" (ici fleurs) est l'ancêtre (catégorie mère ou grand-mère suivant la profondeur des catégories).
lorsque l'on fait cela sur une seul table, on indique qu'un ancêtre n'a pas d'ancêtre
sinon on indique qu'elle ligne est l'ancêtre
exemple de table
id int <= clef primaire de la table
idparent <= correspond a la clef primaire de la catégorie supérieures (si cette ligne correspond a rose, c'est l'id de fleur) et s'il s'agit "d'un ancêtre", donc une catégorie "racine" cette valeur vaut zéro. Pourquoi zéro ? parce que généralement la numération des clef commence à 1 donc si l’ancêtre est zéro on est sur qu'il n'y a pas de recherche d’ancêtre a faire
etc etc
a priori ça c'est déjà fait, par contre pour ce qui est des "conso" associées la il va falloir deux tables en plus pour gérer les relations.
une table "conso"
par exemple
idconso clef primaire
nom varchar
description text
et une table qui fait la liaison entre la table conso et la table des produits
exemple
id
idconso
idproduit
donc au final ton application devrait avoir, au moins, 4 tables,
une table catégorie (clef primaire,ancetre, nom, descriptions)
une table produit (clef primaire, categorie,nom, description) catégorie étant la valeur de la clef primaire correspondant a la catégorie dans la table "catégorie)
une table consomable (clef primaire, nom, description)
une table produitconso (clef primaire, consommable, produit), consommable et produit correspondent au clef primaire des tables des consommables et des produits.
pourquoi une telle architecture ? simplement pour te permettre d'avoir plusieurs consommable pour un produit et d'utiliser un même consommable pour plusieurs produit (j'imagine que le p'tit pot de présentation peux être le même pour une rose blanche ou rouge
)
avec ça tu peux facilement retrouver les consos associés a chaque produit a l'aide d'une jointure.
plus d'info sur SQL =>
http://sqlpro.developpez.com
@+
