1

Plop. Travaillant actuellement sur un projet d'application web type e-commerce, je me retrouve devant un problème auquel j'envisage quelques solutions, mais rien de simple ou léger à première vue. Que je vous explique.

Mettons que mon application permette à un commerçant de vendre un produit (une robe par exemple) où il peut préciser des paramètres (dans notre exemple, des tailles disponibles et des couleurs disponibles) en précisant les stocks disponibles pour chaque combinaison, dans le genre :
36 | rouge | 10 unités
38 | rouge | 15 unités
36 | bleu  | 12 unités
...

Cette application pouvant vendre de tout et de rien, les paramètres sont susceptibles d'évoluer entre les produits, mais surtout pour un produit donné, il faut gérer les stocks de chaque combinaison de paramètres possibles, pour un nombre indéfini de paramètres (je pense stocker les paramètres dans une table du genre [ nomParam1 - valeurParam1 - nomParam2 - valeurParam2...] jusqu'à 4 paramètres maximum. Je pourrais alors faire une entité associative entre les paramètres et le produit en mettant le stock comme attribut de cette entité.

Cependant, je me demande donc s'il n'y a pas plus simple ou léger comme dit plus haut. Par exemple, pour un vêtement proposé sur 6 tailles différentes, 3 couleurs différentes, on obtient 18 stocks différents (donc 18 associations dans la base), et même si c'est fonctionnel cela me semble à première vue... peu optimisé. Je me demandais si quelqu'un aurait une meilleure approche ou solution à ce problème ?
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

2

il y a tout un tas de solutions possibles on peut imaginer par exemple :
- création d'une table de produits
- création d'une table de "paramètres" spécifiant une catégorie (taille) et une valeur (36)
- création d'une table de stock(20pcs) avec des index paramètre et produit
ça a l'avantage de ne pas devoir recréer les paramètres à chaque fois, tu pioches dans le dictionnaire par contre il faut manipuler des jointures

sinon plus "monolithique":
- création d'une table de produits avec un index supplémentaire sur une catégorie (taille 36) contenant aussi le stock(20pcs)
ça permet une simplification des accès (pas de jointures) mais ça implique beaucoup de duplications de données...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

3

Le problème est que rien n'est connu d'avance (produit, paramètres, stocks), il s'agit de ventes privées où des vendeurs de tout bord peuvent proposer n'importe quoi. Les cas où deux vendeurs vendent le même produit est pour ainsi dire nul, le cas où un vendeur vend deux fois le même produit est supposé relativement rare.
avatar
« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

4

pour un résultat approchant il faut la première solution de vince.

sinon tu devras avoir une table intermédiaire 'jeu de paramètres' qui permet d'associer un stock à une sélection de paramètres pour un produit donné.

Ca me semble inutilement compliqué, il suffit de multiplier les paramètres (36_rouge, 36_vert, etc) pour éviter ce bazar.

5

Je crois que c'est presque ce que vince propose : id
typevalue
1taille36
2taille37
3couleurbleu
4taille38
5couleurrouge

id
produitstock
1bidule4
2machin1
3bidule3
4bidule5
5truc2

id_produit
id_attribut(explication)
11le bidule 1 est de taille 36
13le bidule 1 est bleu
21le machin 2 est de taille 36
23le machin 2 est bleu
31le bidule 3 est de taille 36
35le bidule 3 est rouge
42le bidule 4 est de taille 37
45le bidule 4 est rouge
54le truc 5 est de taille 38
55le truc 5 est rouge

Tu peux chercher facilement tous les items avec un attribut particulier
Tu peux chercher facilement toutes les versions d'un item (indexer la colonne produit quand meme, et si tu as vraiment beaucoup de references, remplacer le nom par un index dans une table contenant les noms)

Le principal inconvénient c'est que la cohérence de la chose dépend de l'appli. Rien ne t'empeche, si tu le veux, d'avoir un item avec deux tailles (remarque ca peut aussi être un avantage)