Bonjour,

j'aurais besoin d'un avis sur la conception des variations d'un produit d'une boutique ecommerce. Par variations j'entend la possibilité d'acheter un t-shirt L, M, XL en rouge, vert ou bleu par exemple!

J'ai du mal a expliquer le probleme tellement c'est compliqué pour moi, mais en gros a cause des variations, je me retrouve avec beaucoup de tables et de grosses requetes a gérer car il faut un stock pour chaque variation ainsi que ( je crois ) une "ref produit" différente etc... J'ai limité les variation a 2 mais si on en veut plus c'est vraiment la galere....

j'ai regardé les tables de oscommerce, joomla avec le module ecommerce et autres mais je n'arrive pas a trouver une solution!

Avez vous déjà fait un site ecommerce avec des variations ? Si oui si vous pouviez m'indiquez l'architecture a suivre!

Bonsoir,
Voici quelques idées qui peuvent être tenues comme point de départ.

Deux produits systématiquement différents sont, par exemple, un T-shirt et un Ballon.
Deux produits sensiblement semblables dans leur nature, peuvent être un T-shirt de taille M et un T-shirt de taille L. Or, il ne sont pas les mêmes. Donc, T-shirt est un caractère commun, comme la taille, la couleur, etc. pour des T-shirt. Dans ce cas-là où se situe-il la notion de produit unique?

Effectivement, le produit unique est une référence qui a des exemplaires (quantité en stock)
Les exemplaires peuvent avoir des variations sensibles certes mais qui ne peuvent pas les rendre différents dans leur essence du produit unique.

Tu peux découper la nature d'identification de ton produit en plusieurs sous-identités tout en veillant de garder l'identité unique de l'entité.

Par exemple, Le T-shirt de telle marque, de telle qualité, de telle nomenclature, de telle taille, de telle couleur, coute tant et est stocké en tel nombre d'exemplaires (quantité).

Les niveaux de découpage dépendent des caractéristiques communes à un produit et qui engendrent des variations. Mais en aucun cas, ses variables ne provoqueront la multiplicité de l'entité PRODUIT.

Donc, pour être clair, tu ne dois avoir qu'une seule table "produit" avec des propriétés de base qui permettent ensemble d'identifier d'une façon unique le produit comme la référence, la désignation, le prix, ... Mais tu peux ressortir des tables liées au produit comme taille, couleur, marque, qualité, et même des quantités spécifiques et des prix spécifiques.

Dans l'absolu, le produit peut devenir une généralité de produit (une table mère ou générique) et les découpages en variantes : des spécificités de produit (des tables filles ou spécialisées)

merci pour cette réponse complète!

Le problème vient aussi du fait que je ne sais pas si il faut différencier la réf du produit a cause des ces variations ou non... Tu me diras je peut avoir 2 ref, une pour mysql (invisible) et une pour le commercant (visible)

Suivant tes conseil j'ai créer 8 tables rien que ca! Par contre, je pas créer une table taille ou couleur car les variations de produits sont créer dynamiquement par le commercant. Si tu vois des anomalies dans le nommage de variables ou autre n'hésite pas a m'en faire part.
Comme tu peut le voir ce n'est pas très souple, car j'ai été obligé de limité a 2 attribut si dans 'absolu on veut un t-shirt rouge XL avec une broderie dessus je peut pas le faire...[/code]

[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]

Non, je ne suis pas d'accord sur cette façon de faire, c'est très complexe et ça tiendra pas la route plutard au niveau des programmes. Mais on va essayer de simplifier l'approche du problème.

Pour cela, réponds à ces questions?

• 1. Dis moi, quels sont toutes les variations que tu veux décliner, par exemple, des produits T-shirt?
  2. Donne moi un exemple de page utilisateur où tu va afficher un catalogue et quels sont les critères de recherche que tu souhaite proposer?
  3. Quels sont les informations que tu estime suffisantes pour que l'utilisateur identifie un produit comme un T-shirt et pour que ton programme d'achat valide l'achat de ce produit?

tout d'abord merci encore pour ton aide!

1) les variations à décliner sont imprévisibles, elles doivent être dynamiques car le commerçant peut mettre n'importe quel produit avec n'importe quel variations!

2) les criteres de recherches sont pour le moment : nom du produit, référence, marque, mots clé inscrit par le commercant
les criteres de classement : nom du produit, prix, date, stock

Il y aura plusieurs visualisation des produits :
mosaique: photo + nom du produit + prix
linéaire : photo + nom du produit + courtes description + prix
je sais pas si cela répond a ta question sur l'exemple page utilisateur

3) pour l'utilisateur : le nom du produit + la ou les photos associés ( les photos sont associés au produit de base, les variations n'ont pas d'effet sur les photos, une infobulle sur le photo permettra de désigner le produit par rapport aux variations )

pour le programme d'achat : la c'est plus déliquat, comme le produit de base a qu'une seule réf, le fait d'ajouter des produits modifient peut etre la ref, donc il faudrait 2 ref la ref de base + ref variation


J'avoue etre un peu perdu! Faut t'il une table stock, image, prix ou une table qui regroupe tout ca?
Et surtout comment gérer un nombre de variations variable?

Je n'ai pas tout lu mais pour info ce que tu cherches à définir s'appelle un SKU : http://en.wikipedia.org/wiki/Stock-keeping_unit

Peut-être que ça t'aidera à mettre en place la solution qui te convient, il y a des liens vers des exemples de mise en place de genre de système.

Ok, donc, le plus simple est de considérer comme produit unique, tout produit ayant les mêmes variantes ou caractéristiques et de poser une référence unique sur cet article. Sachant qu'un article unique peut avoir des exemplaires qui peuvent être représentés par la notion de quantité.

Puisque les variantes sont infinies on va les considérer comme des valeurs de caractéristiques bien définies. Par exemple, quand tu dis que la couleur est une variante, en fait, elle est une propriété du produit et se sont les valeurs que peut prendre la couleur qui produisent des variantes du même produit. La notion de taille va provoquer le même découpage.

Tout compte fait, c'est la variante du produit de base (que j'appellerais "famille de produit") qui doit être considérée comme produit unique vendable.

Par exemple, si un client se pointe et choisi son article, il finira par emporter un produit unique (voir en plusieurs exemplaires) s'il décide d'acheter. Le client a donc acheté un produit unique dont les caractéristiques peuvent être des variantes d'autre produits de la même famille.

Concrètement, si j'achéte deux T-shirt Adidas pour homme à manche longue, de couleur blanche et de taille L, alors techniquement, je serai facturé : où : le code "TSHIRT-ADIDAS-H-ML-BLC-L" est la référence unique de l'article décrit par : "T-shirt Adidas pour homme à manche longue, de couleur blanche et de taille L"

Pour revenir sur la notion de famille de produit, il me suffit de faire remarquer que les produits uniques qu'on va vendre peuvent avoir un tronc commun dans leur identité comme sont T-shirt tous les T-shirt qu'on vend qu'ils soient pour homme ou pour femme, etc ... Donc le T-shirt est une famille de produit.

Ainsi de suite. On peut décomposer le système d'identification en plusieurs groupes d'informations mis en relation pour servir le système de recherche multi-critères.

Exemple:

J'ai mis un peu de temps a répondre, car j'ai bien étudié ta structure.
Par contre, je pense qu'on s'est mal compris ou alors c'est moi qui est pas compris

Au niveau du client, il voit par exempe t-shirt nike | t-shirt addidas | t-shirt rebook dans la page qui liste les produits t-shirt. Il voit le prix général du produit avec la photo associé.
Il clique sur t shirt nike et dans la nouvlle page qui présente le produit il va avoir 0 ou plusieurs combobox avec des caractéristiques ( 0 si le produit ne posséde qu'une caractéristique et que du coup le client na pas le choix ). Il va donc avoir le choix entre plusieurs couleurs et plusieurs tailles par exemples rouge S, rouge L, rouge XL ou vert S, vert XL, vert L. Son choix pourra faire varier le prix du t-shirt

Je te dis ca car j'ai vu que dans la table caracteristique il y avait ref_produit associé avec nom_caracteristique en unique alors qu'il paut y avoir plusieurs nom_caracteristique mais pas plusieurs ref_produit associé avec nom_caracteristique associé avec valeur... je sais pas si je suis clair.

1) est-ce juse un oubli ou c'est délibéré? parce qu'en mettant les 3 associés en unique cela devrait fonctionner, non?
2) il n'y a pas de clé primaire dans cette table, je croyais qu'il en fallait tjs une, même si c juste "id" et en auto-incrément

Sinon pour le reste pas bete du tout de créer une famille de produit, comme ca c'est la famille qu'on classe dans les catégories et sous catégories du site pas le produit directement!
Pour les photos, j'ai crée une table a part car il peut y avoir plusieurs photo pour un meme produit ayant les meme caractéristiques ( par ex: photo de face, photo de dos )

ps: j'avais oublié, les caractéristiques sont accesibles partout en mode admin, si je créer un t-shirt en admin j'aurais une liste de caractérisques déjà créer, j'ai plus qu'a cliquer sur celle ci et sélectionner les différentes valeurs possibles pour le produit que je suis en train d'éditer.

1) est-ce juste un oubli ou c'est délibéré? parce qu'en mettant les 3 associés en unique cela devrait fonctionner, non?

J'ai choisi d'associer la référence du produit et le nom de la caractéristique comme index unique parce qu'un produit ne peut être associé avec plusieurs mêmes noms de caractéristique. Par exemple, si la caractéristique est "Couleur" alors un produit "T-shirt" ne peut avoir plusieurs couleurs. C'est logique.
Donc on ne peut avoir dans la table "caracteristique" les enregistrements suivants:
T-shirt-001, Couleur, Vert
T-shirt-001, Couleur, Rouge <-- Erreur: un produit ne doit pas avoir N couleurs à la fois
Mais on pourrait utiliser les mêmes caractéristiques pour des produits différents:
T-shirt-001, Couleur, Vert
T-shirt-001, Taille, S
T-shirt-002, Couleur, Vert
T-shirt-002, Type, S

2) il n'y a pas de clé primaire dans cette table, je croyais qu'il en fallait tjs une, même si c juste "id" et en auto-incrément

La clé primaire n'est pas systématique. Elle sert simplement pour impliquer une table dans des relations avec d'autres tables. Quand la clé primaire existe, elle joue aussi le rôle d'un index unique qui veille sur l'unicité d'un enregistrement. Mais cela reste le rôle propre à un index unique.
Quand ta table ne pointe pas vers une liaison externe, elle n'a pas besoin d'un identifiant clé primaire mais elle peut se contenter d'un index unique pour éviter les doublons d'enregistrements.

Dans notre cas, c'est le cas. La table "caracteristique" est liée à la table "produit" car elle contient une clé étrangère "ref_produit" qui provient de la table "produit" donc le champ "ref_produit" est une clé primaire dans la table "produit". Notre table "caracteristique" ne fait pas de relation avec les autres tables, elle subit la relation avec "produit". Donc à ce niveau de l'analyse, elle doit rester sans clé primaire, mais se contentera d'un index unique comme contrainte d'unicité des enregistrements.

Je développerai avec toi, plutard si tu veux, une analyse plus adaptée à ton cas si tu me donne toutes les précisions suivantes:

• 1. Quels types de produits comptes-tu cibler?
  2. Quels sont les critères pour déterminer le prix d'un produit
  3. Quels sont les critères de regroupement ? types, catégories, familles, ... de produits

Maintenant je commence à comprendre ce que tu veux faire, et je pense qu'on va trouver une solution plus simple, mais adaptée.

T-shirt-001, Couleur, Vert
T-shirt-001, Couleur, Rouge <-- Erreur: un produit ne doit pas avoir N couleurs à la fois
Mais on pourrait utiliser les mêmes caractéristiques pour des produits différents:
T-shirt-001, Couleur, Vert
T-shirt-001, Taille, S
T-shirt-002, Couleur, Vert
T-shirt-002, Type, S

En fait si un tshirt peut avoir plusieurs couleurs, c'est le client de la boutique qui la choisie ainsi que par exemple la taille

1. Quels types de produits comptes-tu cibler?

Tous, c'est le commerçant qui décide de ce qu'il met et il peut mettre ce qu'il veut!

2. Quels sont les critères pour déterminer le prix d'un produit

La j'hésite entre 2 options :
- soit tu définie un prix de base et tu le fais varier selon les variations justement
- soit un prix par variations meme si c'est le meme prix

3. Quels sont les critères de regroupement ? types, catégories, familles, ... de produits

alors la! avant j'avais attriburer a un produit une catégorie et sous catégorie. Mais en réfléchissant il faut pouvoir attribuer plusieurs catégorie a un produit par exemple:
- le tshirt peut aller dans mode homme
- ou tshirt
- ou promotion

En m'appuyant sur ce que tu a fait, j'ai refondu ma bdd en mettant des exemples :

Donc pour t'aider, il y a 3 produit "père" et a l'intérieur des variations
- produit_id = 1, tshirt nike vert et en taille L ou vert et en taille S
- p_id= 2, tshirt addidas sans variations
- p_id=3, pull ralf lauren manche longue ou manche courte

L'utilisateur a clique sur le tshirt par exemple, il arrive sur la fiche produit avec le titre, description etc... mais surtout il doit choisir sa taille entre L ou S avant de mettre dans le panier via une combobox. Evidemment on peut rajouter d'autre couleurs, ce qui au final fait 2 combobox, une couleur et l'autre taille.

Pour le pull, une seule combobox avec le choix entre manche longue ou manche courte ( d'ailleurs un pull manche courte je crois pas que ca existe ou sa s'appelle pas comme ca ^^ )

2. Quels sont les critères pour déterminer le prix d'un produit
La j'hésite entre 2 options :
- soit tu définie un prix de base et tu le fais varier selon les variations justement
- soit un prix par variations meme si c'est le meme prix

Tu peux permettre les deux méthodes en même temps, en prévoyant un champ "prix" au niveau du produit et un champ "prix" dans l'association entre la variation et le produit (table : product_variation) car si chaque variation fait varier le prix d'un produit (comme les options de voitures par exemple) il faut fixer le prix de la variation quand celle-ci est attachée au produit. C'est logique.

3. Quels sont les critères de regroupement ? types, catégories, familles, ... de produits
alors la! avant j'avais attriburer a un produit une catégorie et sous catégorie. Mais en réfléchissant il faut pouvoir attribuer plusieurs catégorie a un produit par exemple:
- le tshirt peut aller dans mode homme
- ou tshirt
- ou promotion

Pour attribuer plusieurs catégories à un produit ou plutôt à sa famille générique il faut faire une association entre les tables "product_family" et "category" qui contiendra les couples : catégorie/famille.

J'ai lu ton dernier script et essayé de le formaliser en y ajoutant tes dernières règles. En voici, le modèle physique et le script MySQL.

j'ai pas encore bien étudier le code mais comment tu fait ces diagrammes? c'est génial !
j'ai rien vu dans phpmyadmin....

J'ai vu que tu ulisais enum('0', '1') au lieu de enum('false', 'true'), il y a une raison particulière? C'est pour que ce soit moint lourd et plus rapide?

Dans la table product_detail tu met product_ref(varchar 20) en clé primaire au lieu de detail_id(smallint 6), la par contre j'aurais pensé que le smallint aurait été plus pertinant vu que c'est plus rapide?!

Tu pourrais expliquer ces 2 choix la?

Pour le true/false sont des valeurs booléennes et le type booléen n'existe malheureusement pas comme type pure en bases de données je préfère les replacer par leurs valeurs numériques (système binaire) 0 pour false et 1 pour true.

Pour la clé primaire de "product_details", c'est juste un choix. Toi tu as fait un "detail_id" numérique entier comme clé primaire pour des raisons techniques de performance de la relation et l'indexation. Moi j'ai choisi le "product_ref" qui, lui, représente vraiment un produit unique fonctionnellement parlant. Cela evitera de gerer en parallèle un id supplémentaire et ajouter un index unique supplémentaire. Car dans les deux cas t'es obligé d'avoir un index unique sur "product_ref".

Pour le schéma de la base, j'ai utiliser un désigner qui génère automatiquement la base SQL à partir de modèle physique conçu ou l'inverse. Il y en a une panoplie : Amc designer, MicroOLAP Designer..., Navicat, DbDesigner, ... ce dernier est produit Mysql, il est gratuit ici:
http://www.fabforce.net/downloadfile.php
ou pour le workbench: http://dev.mysql.com/downloads/workbenc ... _-_Windows

ok cool j'ai télécharger celui de fabforce et c'est pas mal du tout!
Pour le reste, j'ai 2-3 simulation ca a l'air ok, tout fonctionne comme cela devrait, par contre j'ai plusieurs avertissements comme "La colonne `product_id` ne devrait pas faire partie à la fois d'une clé primaire et d'une clé index".
C'est normal ? C'est peut etre dû a ma version de mysql (5.0.45)

Non ce n'est pas normal d'avoir le champ "product_id" à la fois comme clé primaire et index dans une même table. Et étant donné que product_id est la clé primaire de la table "product" elle ne doit pas figurer dans les autres index de cette table, car une clé primaire est déjà par définition un index unique.
Toute fois, ce même champ "product_id" peut être utilisé comme clé étrangère dans d'autres tables en de dehors de la table "product" comme par exemple, la table "product_details". C'est logique.

La règle est qu'un champ qui est défini comme clé primaire dans une table ne peut être redéclaré comme index unique ou avec doublons dans la même table mais peut être utilisé comme clé étrangère (c'est à dire : index avec doublons) dans d'autres tables.

Ce principe ne dépend pas de la version de MySQL.