Page 1 sur 2
Conception de variations pour boutique ecommerce
Posté : 19 déc. 2008, 19:03
par toojee
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!
Posté : 19 déc. 2008, 21:49
par sadeq
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)
Posté : 20 déc. 2008, 11:45
par toojee
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.
Code : Tout sélectionner
//ici j'ai mis les categorie_id et categorie_detail_id pour classer le produit dans le bon menu
// il y a aussi les 2 id des variations possibles associé au produit pour pouvoir les afficher dans des combobox
- [b]produit[/b] : produit_id | produit_actif | produit_ref | produit_prix_ht | produit_tva | produit_ecotaxe | variation_id_1 | variation_id_2 | categorie_id | categorie_detail_id | mdate
//ici le position permet de classer l'ordre d'apparition des combobox
-[b]produit_variation [/b]: variation_id | position
------------------------------1-------------0
// ici c'est la table des textes des noms des variations comme taille ou couleur. C'est en plusieurs langues
- [b]produit_variation_texte[/b] : id | attribut_id | langue | titre | texte
--------------------------------1---------1----------fr------var1----couleur
//ici on ajoute des valeur pour couleur ou taille par ex M, L, XL ou rouge vert bleu
-[b]produit_variation_valeur[/b] : attribut_valeur_id | attribut_id | position | valeur_prix | valeur_prefixe
---------------------------------------1-----------------1-----------0------------5.50-------------5
//ici c'est comme tout a lh'eure cela permet d'avoir plusieurs langue mais pour les valeurs
-[b]produit_variation_valeur_texte[/b] : id | variation_valeur_id | langue | titre | texte
--------------------------------------1-------------1-------------fr-------couleur1----rouge
//ici on stocke les images, l'image qui a le plus petite position est l'image que l'on voit dans la mosaique des produits
- [b]produit_image [/b]: image_id | produit_id | position | url_thumb_img | url_full_img
-------------------------1----------------1----------0---------img/tshirt1.jpg-------------img/tshirt1_full.jpg
//ici la gestion du stock par variation par exemple variation_valeur_id_1 =>M et variation_valeur_id_2 => rouge | pour 3 couleur et 3 taille ca fait 3*3 stock différent!
- [b]produit_stock[/b] : stock_id | produit_id | unite | alerte | variation_valeur_id_1 | variation_valeur_id_2
-----------------------1-----------1------------5------1---------------1------------------------2
//ici le texte du produit en plusieurs langues
- [b]produit_texte [/b]: texte_id | produit_id | langue | titre | texte
----------------------1-----------1-----------fr---------Mon t-shirt -----ce t-shirt est magnifique
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]
Posté : 20 déc. 2008, 13:25
par sadeq
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?
Posté : 20 déc. 2008, 20:13
par toojee
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?
Posté : 20 déc. 2008, 21:45
par ouckileou
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.
Posté : 21 déc. 2008, 01:29
par sadeq
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é :
Code : Tout sélectionner
Produit référencé : TSHIRT-ADIDAS-H-ML-BLC-L et quantité achetée =2
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:
Code : Tout sélectionner
-- phpMyAdmin SQL Dump
-- version 2.11.6
-- http://www.phpmyadmin.net
--
-- Serveur: localhost
-- Généré le : Dim 21 Décembre 2008 à 00:28
-- Version du serveur: 5.0.51
-- Version de PHP: 5.2.6
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
--
-- Base de données: `ecom`
--
-- --------------------------------------------------------
--
-- Structure de la table `famille`
--
CREATE TABLE `famille` (
`id_famille` int(11) NOT NULL auto_increment,
`description` text,
`categorie` VARCHAR(255),
PRIMARY KEY (`id_famille`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ;
--
-- Contenu de la table `famille`
--
INSERT INTO `famille` (`id_famille`, `description`, `categorie`) VALUES
(1, 'T-shirt', 'Vêtement'),
(2, 'TV', 'Audio-Vidéo),
(3, 'Pull', 'Vêtement'),
(4, 'DVD', 'Audio-Vidéo);
-- --------------------------------------------------------
--
-- Structure de la table `produit`
--
CREATE TABLE `produit` (
`reference` int(11) NOT NULL,
`id_famille` int(11) default NULL,
`marque` varchar(255) NOT NULL,
`nom` varchar(50) NOT NULL,
`description` text,
`prix` float NOT NULL,
`photo` varchar(255) default NULL,
`qte_stock` int(11) NOT NULL,
PRIMARY KEY (`reference`),
KEY `ref_famille` (`id_famille`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--
-- Contenu de la table `produit`
--
INSERT INTO `produit` (`reference`, `id_famille`, `marque`, `nom`, `description`, `prix`, `photo`, `qte_stock`) VALUES
(11, 1, 'Adidas', 'T-shirt Femme Rouge taille S', NULL, 20, NULL, 10),
(12, 1, 'Adidas', 'T-shirt Homme Rouge taille L', NULL, 25, NULL, 50),
(21, 2, 'Samsung', 'HDTV LCD 94 cm (37")', NULL, 600, NULL, 10),
(22, 2, 'Panasonic', 'HDTV Plasma 107 cm (42")', NULL, 900, NULL, 10);
-- --------------------------------------------------------
--
-- Structure de la table `caracteristique`
--
CREATE TABLE `caracteristique` (
`ref_produit` int(11) NOT NULL auto_increment,
`nom_caracteristique` varchar(50) NOT NULL,
`valeur` varchar(50) NOT NULL,
UNIQUE KEY `ref_produit` (`ref_produit`,`nom_caracteristique`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=33 ;
--
-- Contenu de la table `caracteristique`
--
INSERT INTO `caracteristique` (`ref_produit`, `nom_caracteristique`, `valeur`) VALUES
(11, 'Couleur', 'Rouge'),
(11, 'Genre', 'Femme'),
(11, 'Taille', 'S'),
(12, 'Couleur', 'Rouge'),
(12, 'Genre', 'Homme'),
(12, 'Taille', 'L'),
(21, 'Format/Norme', 'HD Ready'),
(21, 'TailleDalle', '94 cm (37")'),
(21, 'TypeDalle', 'LCD'),
(22, 'Format/Norme', 'HD TV 1080p'),
(22, 'TailleDalle', '107 cm (42")'),
(22, 'TypeDalle', 'Plasma');
Posté : 22 déc. 2008, 17:32
par toojee
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.
Posté : 22 déc. 2008, 19:51
par sadeq
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.
Posté : 24 déc. 2008, 19:49
par toojee
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 :
Code : Tout sélectionner
-- phpMyAdmin SQL Dump
-- version 2.11.6
-- http://www.phpmyadmin.net
--
-- Serveur: localhost
-- Généré le : Mer 24 Décembre 2008 à 18:35
-- Version du serveur: 5.0.51
-- Version de PHP: 5.2.6
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
--
-- Base de données: `test`
--
-- --------------------------------------------------------
--
-- Structure de la table `product`
--
CREATE TABLE `product` (
`product_id` smallint(6) unsigned NOT NULL auto_increment,
`family_id` smallint(4) unsigned NOT NULL,
`active` enum('false','true') collate utf8_unicode_ci NOT NULL default 'false',
`consultation` int(11) NOT NULL,
`cdate` datetime NOT NULL,
`mdate` datetime NOT NULL,
PRIMARY KEY (`product_id`),
KEY `family_id` (`family_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=4 ;
--
-- Contenu de la table `product`
--
INSERT INTO `product` (`product_id`, `family_id`, `active`, `consultation`, `cdate`, `mdate`) VALUES
(1, 1, 'true', 3, '0000-00-00 00:00:00', '0000-00-00 00:00:00'),
(2, 1, 'true', 0, '0000-00-00 00:00:00', '0000-00-00 00:00:00'),
(3, 2, 'true', 2, '0000-00-00 00:00:00', '0000-00-00 00:00:00');
-- --------------------------------------------------------
--
-- Structure de la table `product_details`
--
CREATE TABLE `product_details` (
`detail_id` mediumint(6) unsigned NOT NULL auto_increment,
`product_id` smallint(6) unsigned NOT NULL,
`reference` varchar(20) collate utf8_unicode_ci NOT NULL,
`prix_ht` decimal(10,2) NOT NULL,
`tva` decimal(10,2) NOT NULL,
`ecotaxe` decimal(10,2) NOT NULL,
`promotion` decimal(10,2) NOT NULL,
`poids` decimal(10,2) NOT NULL,
`ean` char(13) collate utf8_unicode_ci NOT NULL,
`brand` varchar(30) collate utf8_unicode_ci NOT NULL,
`waranty` smallint(6) unsigned NOT NULL,
`max_quantity` smallint(6) unsigned NOT NULL,
`stock_management` enum('false','true') collate utf8_unicode_ci NOT NULL,
`unit` smallint(3) NOT NULL,
`unit_alert` smallint(3) NOT NULL,
`available` date NOT NULL,
`max_delay` smallint(3) unsigned NOT NULL,
PRIMARY KEY (`detail_id`),
UNIQUE KEY `reference` (`reference`),
KEY `product_id` (`product_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=6 ;
--
-- Contenu de la table `product_details`
--
INSERT INTO `product_details` (`detail_id`, `product_id`, `reference`, `prix_ht`, `tva`, `ecotaxe`, `promotion`, `poids`, `ean`, `brand`, `waranty`, `max_quantity`, `stock_management`, `unit`, `unit_alert`, `available`, `max_delay`) VALUES
(1, 1, '8ufg515gh', '20.00', '19.60', '0.00', '0.00', '200.00', '9dfdfd15d1', 'nike', 0, 20, 'true', 5, 1, '0000-00-00', 20),
(2, 1, '8ufg51fg5fd', '22.00', '19.60', '0.00', '0.00', '200.00', 'fg4f8g4fg54', 'nike', 0, 30, 'true', 10, 1, '0000-00-00', 20),
(3, 2, '5ffg45fg', '35.00', '19.60', '0.00', '0.00', '500.00', '6df5d6gf6df', 'addidas', 0, 30, 'true', 15, 1, '0000-00-00', 0),
(4, 3, '69dfd4f548', '36.00', '19.60', '0.00', '0.00', '352.00', '2fd96f5d6f5', 'ralf lauren', 0, 10, 'true', 5, 1, '0000-00-00', 0),
(5, 3, '69dfd4f549', '39.90', '19.60', '0.00', '0.00', '355.00', '4sd54d5f', 'ralf lauren', 0, 0, 'true', 9, 1, '0000-00-00', 0);
-- --------------------------------------------------------
--
-- Structure de la table `product_family`
--
CREATE TABLE `product_family` (
`family_id` smallint(4) unsigned NOT NULL auto_increment,
`category_id` smallint(4) NOT NULL,
`title` varchar(30) collate utf8_unicode_ci NOT NULL,
PRIMARY KEY (`family_id`),
KEY `category_id` (`category_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=3 ;
--
-- Contenu de la table `product_family`
--
INSERT INTO `product_family` (`family_id`, `category_id`, `title`) VALUES
(1, 1, 't-shirt'),
(2, 1, 'pull');
-- --------------------------------------------------------
--
-- Structure de la table `product_images`
--
CREATE TABLE `product_images` (
`image_id` smallint(4) unsigned NOT NULL auto_increment,
`product_id` mediumint(6) unsigned NOT NULL,
`position` smallint(2) NOT NULL,
`url_thumb_image` varchar(255) collate utf8_unicode_ci NOT NULL,
`url_full_image` varchar(255) collate utf8_unicode_ci NOT NULL,
`active` enum('false','true') collate utf8_unicode_ci NOT NULL default 'false',
PRIMARY KEY (`image_id`),
KEY `variation_id` (`product_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=9 ;
--
-- Contenu de la table `product_images`
--
INSERT INTO `product_images` (`image_id`, `product_id`, `position`, `url_thumb_image`, `url_full_image`, `active`) VALUES
(4, 1, 1, 'tshirt-nike-vert-L.jpg', 'tshirt-nike-vert-L_full.jpg', 'true'),
(5, 1, 2, 'tshirt-nike-vert-S.jpg', 'tshirt-nike-vert-S_full.jpg', 'true'),
(6, 2, 0, 'tshirt-addidas-pas-de-variations.jpg', 'tshirt-addidas-pas-de-variations_full.jpg', 'true'),
(7, 3, 1, 'pull-ralfLauren-manche_courte.jpg', 'pull-ralfLauren-manche_courte_full.jpg', 'true'),
(8, 3, 2, 'pull-ralfLauren-manche_longue.jpg', 'pull-ralfLauren-manche_longue_full.jpg', 'true');
-- --------------------------------------------------------
--
-- Structure de la table `product_variations`
--
CREATE TABLE `product_variations` (
`detail_id` mediumint(6) unsigned NOT NULL,
`variation_id` mediumint(6) NOT NULL,
UNIQUE KEY `detail_id` (`detail_id`,`variation_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
--
-- Contenu de la table `product_variations`
--
INSERT INTO `product_variations` (`detail_id`, `variation_id`) VALUES
(1, 2),
(1, 5),
(2, 2),
(2, 4),
(4, 8),
(5, 7);
-- --------------------------------------------------------
--
-- Structure de la table `text_product`
--
CREATE TABLE `text_product` (
`product_id` smallint(4) unsigned NOT NULL,
`language` char(2) collate utf8_unicode_ci NOT NULL,
`title` varchar(30) collate utf8_unicode_ci NOT NULL,
`description` text collate utf8_unicode_ci NOT NULL,
`cdate` datetime NOT NULL,
`mdate` datetime NOT NULL,
UNIQUE KEY `product_id` (`product_id`,`language`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
--
-- Contenu de la table `text_product`
--
INSERT INTO `text_product` (`product_id`, `language`, `title`, `description`, `cdate`, `mdate`) VALUES
(1, 'fr', 'T-shirt nike', 'Ce t-shirt est magnifique!', '0000-00-00 00:00:00', '0000-00-00 00:00:00'),
(1, 'en', 'T-shirt nike', 'This t-shirt is amazing!', '0000-00-00 00:00:00', '0000-00-00 00:00:00'),
(2, 'fr', 'T-shirt addidas', 'Ce tshirt n''est pas mal non plus', '0000-00-00 00:00:00', '0000-00-00 00:00:00'),
(3, 'fr', 'Pull ralf lauren', 'Avec ce pull vous n''aurez plus jamais froid!', '0000-00-00 00:00:00', '0000-00-00 00:00:00');
-- --------------------------------------------------------
--
-- Structure de la table `variations`
--
CREATE TABLE `variations` (
`variation_id` mediumint(6) unsigned NOT NULL auto_increment,
`title` varchar(20) collate utf8_unicode_ci NOT NULL,
`value` varchar(20) collate utf8_unicode_ci NOT NULL,
PRIMARY KEY (`variation_id`),
UNIQUE KEY `title` (`title`,`value`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=9 ;
--
-- Contenu de la table `variations`
--
INSERT INTO `variations` (`variation_id`, `title`, `value`) VALUES
(1, 'couleur', 'rouge'),
(2, 'couleur', 'vert'),
(3, 'couleur', 'bleu'),
(4, 'taille', 'S'),
(5, 'taille', 'L'),
(6, 'taille', 'XL'),
(7, 'manche', 'longue'),
(8, 'manche', 'courte');
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 ^^ )
Posté : 26 déc. 2008, 20:23
par sadeq
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.
Code : Tout sélectionner
-- =============================================================================
-- Diagram Name: ecommerce
-- Created on: 26/12/2008 18:55:31
-- Diagram Version: 1.0
-- =============================================================================
CREATE DATABASE IF NOT EXISTS `ecommerce`
CHARACTER SET utf8
COLLATE utf8_unicode_ci;
USE `ecommerce`;
SET FOREIGN_KEY_CHECKS=0;
CREATE TABLE `category` (
`category_id` smallint(6) NOT NULL,
`title` varchar(50) CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL,
PRIMARY KEY(`category_id`)
)
ENGINE=INNODB
COMMENT = 'InnoDB free: 5120 kB';
CREATE TABLE `product` (
`product_id` smallint(6) UNSIGNED NOT NULL AUTO_INCREMENT,
`family_id` smallint(6) UNSIGNED NOT NULL,
`active` enum('0','1') CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
`consultation` int(11) NOT NULL,
`cdate` datetime NOT NULL,
`mdate` datetime NOT NULL,
PRIMARY KEY(`product_id`),
INDEX `FK_family`(`family_id`)
)
ENGINE=INNODB;
CREATE TABLE `product_details` (
`product_ref` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`product_id` smallint(6) UNSIGNED NOT NULL,
`prix_ht` decimal(10,2) NOT NULL,
`tva` decimal(10,2) NOT NULL,
`ecotaxe` decimal(10,2) NOT NULL,
`promotion` decimal(10,2) NOT NULL,
`poids` decimal(10,2) NOT NULL,
`ean` char(13) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`brand` varchar(30) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`waranty` smallint(6) UNSIGNED NOT NULL,
`max_quantity` smallint(6) UNSIGNED NOT NULL,
`stock_management` enum('0','1') CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
`unit` smallint(6) NOT NULL,
`unit_alert` smallint(6) NOT NULL,
`available` datetime NOT NULL,
`max_delay` smallint(6) UNSIGNED NOT NULL,
PRIMARY KEY(`product_ref`),
INDEX `FK_product`(`product_id`)
)
ENGINE=INNODB;
CREATE TABLE `product_family` (
`family_id` smallint(6) UNSIGNED NOT NULL AUTO_INCREMENT,
`title` varchar(30) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY(`family_id`)
)
ENGINE=INNODB;
CREATE TABLE `product_images` (
`image_id` smallint(6) NOT NULL,
`product_id` smallint(6) UNSIGNED NOT NULL,
`position` smallint(6) NOT NULL,
`url_thumb_image` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`url_full_image` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`active` enum('0','1') CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '0',
PRIMARY KEY(`image_id`),
INDEX `FK_product`(`product_id`)
)
ENGINE=INNODB;
CREATE TABLE `product_text` (
`product_id` smallint(6) UNSIGNED NOT NULL,
`language` char(2) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`title` varchar(30) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`description` text CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`cdate` datetime NOT NULL,
`mdate` datetime NOT NULL,
PRIMARY KEY(`product_id`, `language`),
INDEX `FK_product`(`product_id`)
)
ENGINE=INNODB;
CREATE TABLE `variations` (
`variation_id` smallint(6) UNSIGNED NOT NULL AUTO_INCREMENT,
`title` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`value` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY(`variation_id`),
UNIQUE INDEX `variation_title`(`title`, `value`)
)
ENGINE=INNODB;
CREATE TABLE `product_variations` (
`product_ref` varchar(20) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
`variation_id` smallint(6) UNSIGNED NOT NULL DEFAULT '0',
`prix_ht` decimal(10,2),
INDEX `FK_product_details`(`product_ref`),
INDEX `FK_variation`(`variation_id`),
UNIQUE INDEX `Ligne_unique`(`product_ref`, `variation_id`)
)
ENGINE=INNODB;
CREATE TABLE `category_product_family` (
`family_id` smallint(6) UNSIGNED NOT NULL DEFAULT '0',
`category_id` smallint(6) NOT NULL DEFAULT '0',
INDEX `FK_category`(`category_id`),
INDEX `FK_family`(`family_id`),
UNIQUE INDEX `Ligne_unique`(`category_id`, `family_id`)
)
ENGINE=INNODB;
ALTER TABLE `product` ADD
CONSTRAINT FOREIGN KEY (`family_id`)
REFERENCES `product_family`(`family_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE `product_details` ADD
CONSTRAINT FOREIGN KEY (`product_id`)
REFERENCES `product`(`product_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE `product_images` ADD
CONSTRAINT FOREIGN KEY (`product_id`)
REFERENCES `product`(`product_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE `product_text` ADD
CONSTRAINT FOREIGN KEY (`product_id`)
REFERENCES `product`(`product_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE `product_variations` ADD
CONSTRAINT FOREIGN KEY (`product_ref`)
REFERENCES `product_details`(`product_ref`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE `product_variations` ADD
CONSTRAINT FOREIGN KEY (`variation_id`)
REFERENCES `variations`(`variation_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE `category_product_family` ADD
CONSTRAINT FOREIGN KEY (`family_id`)
REFERENCES `product_family`(`family_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
ALTER TABLE `category_product_family` ADD
CONSTRAINT FOREIGN KEY (`category_id`)
REFERENCES `category`(`category_id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
SET FOREIGN_KEY_CHECKS=1;
Posté : 26 déc. 2008, 20:59
par toojee
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?
Posté : 26 déc. 2008, 23:33
par sadeq
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
Posté : 30 déc. 2008, 17:28
par toojee
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)
Posté : 30 déc. 2008, 20:15
par sadeq
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.