Ca confirme ce que je pensais. Il ne faut pas faire comme ça, ce serait une erreur d'analyse.
Quand je parle d'admin, je ne parle pas d'administration du site, mais de la base de données. Ce sont deux choses différentes : l'admin du site correspond au fonctionnement normal de l'application, à l'intérieur duquel la base ne DOIT PAS être modifiée (sous aucun prétexte), alors que l'administration de la base de données correspond à une phase de développement ou de maintenance de l'application (mais pas du site), dans laquelle la modification de la base de données est possible, puisque s'intégrant dans un processus d'amélioration de l'application.
Ce que tu dois faire, c'est considérer les attributs de tes produits comme des données que tu associes à chaque produit. C'est la relation attribut-produit qui détermine si le produit possède tel ou tel attribut.
Définissons une table produits basique comme celle que tu as décrite :
PRODUITS
- produit_id
- produit_libelle
- produit_descriptif
- produit_prix
- produit_unite
Définissons maintenant ce qu'est un attribut :
ATTRIBUTS
- attribut_id
- attribut_nom
C'est à peu près tout. Un attribut, en lui-même, n'est pas besucoup plus que ça.
Si tu vends des claviers d'ordinateur, tu as besoin d'indiquer des caractéristiques qui ne sont pas communes à tous les produits, comme par exemple :
- marque
- connectique
- multimédia
Tu vas insérer de nouveaux enregistrements dans la table attributs. Bien. Maintenant, pour savoir quel produit possède quel attribut, il faut faire une relation entre les deux. Cette relation permet donc de définir quel attribut possède un produit : elle doit nécessairement indiquer la valeur de l'attribut. En analyse, on appelle ça une propriété portée, et la relation attribut-produit est une relation n,n : un même produit peut avoir plusieurs attributs, un même attribut peut être associé à plusieurs produits. Concrètement, dans un MLD (Modèle logique de Données dans la méthode Merise), la relation attribut-produit est représentée comme ceci :
ATTRIBUT-PRODUIT
- attribut_id
- produit_id
- attr_valeur
La clé primaire étant la concaténation des deux ID attribut_id et produit_id
Reprenons l'exemple des claviers. Dans la table produits, on aurait quelque chose comme ça :
produit_id produit_libelle produit_descriptif produit_prix produit_unite
1 Clavier 105T Logitech Blabla du clavier génial 30 -
2 Clavier Sans Fil Blabla multimédia tout ça 60 -
3 Clavier lumineux Luminosité réglable blabla 80 -
Dans la tabe attributs, on aurait :
attribut_id attribut_nom
1 marque
2 connectique
3 multimedia
Enfin, la table matérialisant la relation attribut-produit comporterait :
attribut_id produit_id attr_valeur
1 1 Logitech
2 1 USB
3 1 Non
1 2 Microsoft
2 2 Sans fil
3 2 Oui
1 3 Logitech
2 3 USB
3 3 Oui
Lorsque tu récupères les informations sur un produit, une jointure sur la table de relation et la table attributs te permet de récupérer par la même occasion les différents attributs spécifiques à ce produit ainsi que sa valeur (marque Logitech, connectique USB, etc).
Cela rend ta base de données suffisament générique pour pouvoir gérer n'importe quel type de produit. Si la relation entre un produit et un attribut n'existe pas, alors c'est que ce produit n'a tout simplement pas cet attribut. Sinon, la valeur est définie dans la propriété portée attr_valeur.
Ton prof n'a pas à "injecter" un fichier XML pour vérifier que ta base est suffisament générique : la simple utilisation de l'interface d'admin permet de le vérifier, de même que la consultation du MCD, du MLD et du MPD.
Est-ce que mon explication à moi est plus claire comme ça ?
--
Neige
Souvent la réponse à votre question se trouve dans la
doc. Commencez par là ;)