Gestion de produits - Site d'e-commerce

Bonjour,

Je suis actuellement en train de développer un panier d'achats pour sites d'e-commerce ASP.NET utilisant C#. Le problème étant que ce panier doit pouvoir s'adapter sur n'importe quel site. J'ai donc un problème avec la gestion de mes produits qui suit le même principe de portabilité.

Je ne sais pas trop comment gérer les options/caractéristiques d'un produit.
J'ai donc un table 'produits' contenant un id, un nom, un prix (pour faire simple). Je voudrais pouvoir lui associer des options comme une couleur ou une taille un poids, bref peu importe, je veux juste lui associer une caratéristique.
J'ai donc pensé créer un table 'options' qui contiendrait donc les différentes sortes de caractéristiques: taille, poids, couleur, etc... et à créer ces tables (couleurs, taille, ...) contenant des valeurs.

Ainsi dans ma table 'produits', j'ajoute la sorte de caractéristique à partir de la table 'options' et la valeur choisie de la caractéristique voulue.

Mon problème est multiple:
- comment faire si je veux associer plusieurs options à mon produit ?
- comment faire si tel produit n'existe que pour deux caractéristiques (par ex) alors que la table en contient une dizaine.

Je précise qu'il faut rester le plus générique possible. J'espère m'être fait comprendre.
Merci.
Zllzn

Salut,

La solution la plus générique et qui s'adapte à tout serait de faire une table produits contenant l'idProduit, le prix et le nom, et une table options contenant l'idOption, idProduit, typeOption et valeurOption.

Avec une telle architecture : peu importe le nombre d'options possibles (et le nombre de produits auxquels elles s'appliquent) : tu crée une ligne par option/produit.

Du style : tu as le produit stylo qui peut avoir une couleur différente alors ca te donne :


Maintenant, tu as le produit voiture qui peut avoir comme option une couleur, un nombre de siège, un nombre de porte, alors ca te donne :


Tu as ainsi une architecture optimisée pour le stockage des données (par de champs vide, pas de données redondante).
______________________________________

AVANT de poster votre message, veuillez lire, comprendre, et appliquer notre réglement

Salut,

Déjà merci pour ta réponse. On a finalement opté pour une solution similaire (En fait, on est en binome sur le sujet).
Le problème qui se pose maintenant est lorsque l'on est confronté à une option qui dépend d'une autre option. Par exemple, pour un t-shirt, si l'on en a un rouge qui ne peut qu'avoir les tailles M, L, XL et un t-shirt bleu qui lui ne peut qu'avoir XS, S, M, L. On a deux produits t-shirts mais avec des options différentes.

Ta solution consisterait à dire qu 'un t-shirt rouge et un t-shirt bleu sont deux produits différents. On aimerait éviter de faire ça justement, mais s'il n'y a pas d'autres moyens...

Pour l'instant, on a utilisé ta méthode.

Merci en tous cas.

Salut,

Oui là en effet il vaut mieux avoir 2 produits. Mais tu peux faire une architecture un peu plus évoluées à ce moment là avec une table produit, une table optionsProduits (qui dans ton cas serait les couleurs) et une table sousOptionsProduits (qui dans ton cas serait les tailles) : la table sousOptionsProduits aurait une clé étrangère vers la table optionsProduits qui elle même aurait une clé étrangère vers la table produits.
______________________________________

AVANT de poster votre message, veuillez lire, comprendre, et appliquer notre réglement

Salut,

Le problème est que si l'on fait comme tu as proposé est que l'on devrait créer une table optionsProduits pour chacune de nos options. Je veux dire par là que si la table optionsProduits contient les couleurs, cela marche pour des t-shirts par exemple, mais on ne sqit pqs à l'avance quels genres de produits ou quels genres d'options peuvent avoir ses produits.
Notre panier peut aussi bien contenir des habits que des pièces informatiques, que des frigos ou des posters. Du coup, la table optionsProduits serait différente pour chaque cas d'utilisation.

Pour l'instant, on gère ça avec des strings. Dans la table options produits, on a la taille, la couleur, etc ... et la table optionsValue qui contient l'id du produit, l'id de l'option (qui vient de la table optionsProduits) et une valeur en varchar.
Comme ça on peut mettre aussi bien "XS" que "190*100*50" (par exemple) pour la taille. Mais on peut aussi mettre "5 portes".

Le problème qui se pose alors est que l'on a aucun contrôle sur les valeurs saisies. On peut tout aussi bien saisir "5 portes" que "cinq portes" qui seront deux valeurs différentes.

Salut,

C'est justement le but de la table des sousOptions d'éviter de stocker toutes les options dans une seule table avec autant de champs que d'options existantes !

Le principe est le même que pour la table des options : au lieu de stocker une option par champ, tu stocke une options par enregistrement. Ainsi peut importe le nombre d'options, tu n'a que 2-3 champs, et x enregistrements.

C'est à dire au lieu d'avoir :
TABLE Options (idOption, idProduit, Taille, Couleur, Marque, Longueur, Largeur, Hauteur, Profondeur, NombrePortes, NombreRoues, etc.)

Tu as :
TABLE Options (idOption, IdProduit, typeOptions, Valeur)
Et tu as autant de ligne que de type d'options par produit. Et si ca te suffit pas, tu fais une table des sous-options pour spécialiser un peu plus, sur le même principe.

Je te laisse réfléchir à comment agencer tout cà avec 3 tables (relation ternaire).
______________________________________

AVANT de poster votre message, veuillez lire, comprendre, et appliquer notre réglement

Salut,

Pour la table optionsProduits, on avait qu'une option par enregistrement et non pas par champs.
Notre table optionsProduits, on a :
INSERT INTO (idProduit, nomOption, valeurOption) VALUES (15, "Couleur", "Rouge")
INSERT INTO (idProduit, nomOption, valeurOption)VALUES (46, "Taille", "L")
par exemple.

Ce qui me gene un peu, c'est que "Couleur" et "Taille" sont des Strings, enfin des varchar, et du coup ca laisse trop de liberte a l'utilisateur qui pourra aussi bien rentrer "coulleur", "color", "colour", enfin bref autant de termes plus ou moins juste qui designent le meme type d'option.

Aussi, j'ai pas vraiment compris ce que tu veux mettre dans la table sousOptionProduit.

Salut,

C'est à toi de voir ce que tu veux : si tu veux quelque chose de générique qui s'adapte à tout, tu n'as guère le choix : soit tu stockes dans un champ de type VARCHAR les valeurs, soit tu crées autant de tables qu'il n'y a de types de valeurs possible (entier, chaîne, couleur, immatriculation, distance, code postal, etc. etc. etc.), mais ca va très vite devenir une usine à gaz, et surtout, tu ne pourras jamais tout gérer... donc à toi de voir.

Tu m'as dit que tu ne voulais pas différencier un tee-shirt rouge d'un tee-shirt bleu. Il te faut donc stocker quelque part qu'il existe un produit "tee-shirt". Que ce produit tee-shirt à une option principale "couleur", mais ils ont aussi des sous-options : la taille. Avec un niveau de 3 tables pour : 1/ le produit (tee-shirt), 2/ les options principales du produit (couleur de tee-shirt, marque de voiture, etc.), et 3/ les sous-options (taille de tee-shirt, modèle de voiture, etc.), ca devrait répondre à la plupart des produits tout en gardant un niveau d'optimisation en lecture qui soit assez bon. Tu peux rajouter plus de niveaux d'options si vraiment tu en as besoin, mais attention alors au nombre de jointures dans les requêtes et le nombre de données à gérer qui risque vite d'exploser !
______________________________________

AVANT de poster votre message, veuillez lire, comprendre, et appliquer notre réglement