2010-08-31 11 views
0

Je considère comment structurer ma base de données MySQL dans une solution de commerce électronique. Pour être plus précis, je regarde la structure du produit.structure de commerce électronique pour les produits (MySQL)

Voici les tableaux que j'ai trouvés jusqu'à maintenant. Qu'est-ce que tu penses?

Explication de la structure

L'application est multilingue. Par conséquent, la table des produits est divisée en 2 tables.

Si un produit a par ex. 2 variantes (Small, Medium) un total de 3 lignes sera inséré. C'est parce que chaque variante peut avoir des informations différentes pour chaque variante. Lorsque le produit est affiché sur la page Web, le produit 1 sera affiché avec une boîte déroulante avec le petit & Moyen. Un produit sans variantes n'insérera naturellement qu'une seule ligne.

 
products 
id master product_number 
1 0  123 
2 1  456 
3 1  678

products_descriptions id product_id country_code image name description vat price 1 1 en-us image.jpg t-shirt Nice t-shirt 25 19.99 2 2 en-us image.jpg t-shirt Nice t-shirt 25 19.99 3 3 en-us image.jpg t-shirt Nice t-shirt 25 19.99

products_to_options product_id option_id 2 1 3 2

options id name 1 Small 2 Medium

Répondre

1

Votre tableau de produits est schizophrénique, son entité est parfois Produit et parfois Variante. Cela conduit à un comportement très lourd. Par exemple, vous aimeriez connaître la question "combien de produits différents avons-nous?" être répondu par select count(*) from products, mais ici cela donne la mauvaise réponse, pour obtenir la bonne réponse, vous devez connaître le Magic Number 0 et la requête select count (*) from products where master=0. "Lister tous les produits et combien de variantes nous avons pour chacun" est une autre requête qui devrait être simple mais qui ne l'est pas. Il existe d'autres anomalies, comme le fait que la première ligne dans products_descriptions est une chemise qui a un prix et une image mais pas de taille (la taille est stockée dans les variantes, mais elles ont des prix et des images qui leur sont propres). Votre problème semble être que vous avez des produits dans deux contextes: (1) quelque chose qui peut être affiché comme un article dans votre magasin, et (2) quelque chose qui peut être commandé par votre client. (1) a probablement un nom comme "Halloween T-Shirt" ou plus, et il a probablement une image que le client voit. (2) est ce que le client commande, donc il a un (1), mais aussi une variante de spécification comme "petit" ou peut-être une couleur "rouge". Il a probablement aussi un prix et un order_id pour que votre boutique sache quel article spécifique expédier.

Vous devez attribuer à chaque contexte une entité. Voici comment je le ferais

displayable_product 
id name 
1 "Baseball Cap" 
2 "T-Shirt" 

orderable_product 
id d_product_id order_id size color price 
1 1   123    red  9.99 
2 2   456  small   19.99 
3 2   789  medium   21.99 

displayable_content 
id d_product_id locale name     image 
1 1    en_US "Baseball Cap"  baseballcap.jpg 
2 1    es_US "Gorra de Beisbol" baseballcap.jpg 
3 2    en_US "Nice T-Shirt"  nicetshirt.jpg 
4 2    es_US "Camiseta"   nicetshirt.jpg 

Vous devriez probablement utiliser locale au lieu de country dans les tableaux d'affichage pour tenir compte des pays avec plus d'une langue (Etats-Unis, la Suisse, et d'autres), et vous pourriez séparer le size et color dans son propre tableau variants. Et si vous avez besoin de données dépendantes du pays sur les commandes (comme les différents prix/devises pour les expédier vers différents pays), vous devrez également extraire une table orderable_content dépendante du pays.

+0

Exemple intéressant. Mais que faites-vous si le nombre d'options est inconnu? Comme "Slewvless"? Devriez-vous normaliser cela? – Cudos

+0

Je voudrais essayer de garder la base de données normalisée aussi longtemps que possible. Dans votre cas, j'essaierais de classer les options en deux catégories: (1) celles qui sont structurelles dans le sens où elles pourraient aboutir à des requêtes comme "cette année, combien de clients préfèrent le rouge si le rouge, le blanc et le bleu sont offert ", et (2) ceux qui ressemblent plus à décrire un texte qu'à des catégories. Idéalement, le seau (2) serait vide, mais dans la vraie vie, je peux être plus grand que (1). Mais fondamentalement, si quelque chose apparaît souvent dans les requêtes, je le veux normalisé. Si c'est utilisé uniquement dans les descriptions, alors le mettre dans une table EAV est ok. – wallenborn