Bonjour,

Je crée une boutique en ligne mais rencontre un problème de développement concernant la gestion du stock.
 
Remarque: la boutique doit pouvoir vendre tout type de produit.
 
 
Voici comment je vois les choses:
 
Un produit peut avoir de 0 à plusieurs caractéristiques comme les tailles, les couleurs, ou autres. Pour un même produit, on aura ainsi plusieurs références.
 
Exemples:
 
1er produit: un pantalon
 
tailles: S, M, L
couleurs: Rouge, Bleu
 
ce qui donne les références (avec croisement des caractéristiques):
 
Produit1 - réf1 - S - Rouge - 60 euros - 5 unités
Produit1 - réf2 - S - Bleu - 60 euros - 3 unités
Produit1 - ref3 - M - Rouge - 65 euros - 0 unité
Produit1- ref4 - M - Bleu - 65 euros - 3 unités
Produit1 - réf5 - L - Rouge - 70 euros - 5 unités
Produit1 - réf6 - L - Bleu - 70 euros - 4 unités
(les prix peuvent changer en fonction des caractéristiques)
 
2e produit: une assiette en porcelaine
 
tailles: 22cm, 28cm, 33cm
 
ce qui donne les références:
 
Produit2 - réf1 - 22 - 12 euros - 30 unités
Produit2 - réf2 - 28 - 16 euros - 38 unités
Produit2 - réf3 - 33 - 22 euros - 14 unités
 
 
Au niveau de la bas de données, on doit avoir une table References avec les champs suivants:
 
idProduit - reference - idCaracteristique1 - valeurCaracteristique1 - idCaracteristique2 - valeurCaracteristique2 - prix - stock
 
avec une autre table Caracteristiques:
 
idCaracteristique - nomCaracteristique
 
on a bien sûr aussi une table produits...
 
 
Les problèmes:
 
Il risque d'y avoir de nombreux champs vides  dans la table References puisqu'on peut n'avoir qu'une caractéristique, ou pas du tout.
Si on veut une troisième caractéristique, il faudrait rajouter deux champs dans la table, du coup encore plus de champs vides.
 
 

Quelqu'un aurait-il une autre idée qui permette d'avoir autant de caractéristiques que l'on veut ?
Et un meilleur moyen de gérer le stock ?
 
Merci pour votre aide

Salut,
 
Il me semble que ce serait plus simple de faire une structure un peu plus souple, par exemple :  
 
Une table PRODUIT :
Id_Produit
Nom_Produit
Reference_Produit
Quantite;
Prix;
... (champs techniques, par exemple date de mise à jour de la quantité, date de création du produit, je te laisse voir ce qui peut être utile)
 
Attention, on part bien du principe que ta référence est UNIQUE pour 1 produit et reprend donc l'ensemble des caractéristiques d'un produit, par exemple un jean rouge de taille 38 et un jean bleu de taille 38 n'ont pas la même référence...
 
Par exemple :  
 
Id_Produit;Nom_Produit;Reference_Produit;...
1;Pantalon;145;...
2;Assiette;275...
3;...
 
 
Une table TYPE_CARACTERISTIQUE
Id_Type_Caracteristique
Libelle_Type_Caracteristique
... (toujours les champs techniques)
 
Par exemple :  
 
Id_Type_Caracteristique;Libelle_Type_Caracteristique;...
1;COULEUR;...
2;TAILLE;...
3;FORME;...
4;MATIERE;...
 
Une table CARACTERISTIQUE
Id_Caracteristique
Libelle_Caracteristique
Id_Type_Caracteristique
... (champs techniques, par exemple date de création de la caractéristique, je te laisse voir ce qui peut être utile)
 
Id_Caracteristique;Libelle_Caracteristique;Id_Type_Caracteristique;...
1;ROUGE;1;...
2;38;2;...
3;40;2;...
4;PORCELAINE;4;...
 
Une table INFO_PRODUIT :  
Id_Produit
Id_Caracteristique
... (champs techniques)
 
 
 
On peut donc savoir que la caractéristique 1 est de TYPE "COULEUR", et qu'elle a pour valeur "ROUGE", que la n°2 est de TYPE "TAILLE" et qu'elle vaut 38, et que la n°4 est de TYPE "MATIERE" et qu'elle vaut PORCELAINE...
 
Ensuite, il ne te reste plus qu'à alimenter la table "INFO_PRODUIT", en liant un Id_Produit à un ou plusieurs Id_Caracteristique, avec par exemple :  
 
Id_Produit;Id_Caracteristique;...
2;4;...
2;1;...
1;1;...
1;3;...
 
Ici, on a géré les CARACTERISTIQUES d'un produit, on sait donc que le produit 2 est en PORCELAINE et qu'il est ROUGE.
 
Pour les stocks, puisqu'on est parti du postulat que chaque référence produit était unique, il faut stocker les champs QUANTITE et PRIX dans la table PRODUIT.
(ce ne sont plus les caractéristiques qui font varier le prix d'un produit, mais bien sa référence).
 
Dans tous les cas, dis toi que si tu es confronté à un problème de nombre de champs dans une table (à savoir ce nombre peut varier), c'est que ton modèle n'est pas le bon...