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
Exemple intéressant. Mais que faites-vous si le nombre d'options est inconnu? Comme "Slewvless"? Devriez-vous normaliser cela? – Cudos
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