Структура электронной коммерции для продуктов (MySQL)

Question

Я рассматриваю, как структурировать мою базу данных MySQL в решении для электронной коммерции. Чтобы быть более конкретным, я рассматриваю структуру продукта.

Это те таблицы, которые я придумал до сих пор. Как вы думаете?

Объяснение структуры

Заявка многоязычен. Поэтому таблица продуктов разделяется на две таблицы.

Если продукция имеет, например, 2 варианта (Small, Medium) будут вставлены в общей сложности 3 строки. Это связано с тем, что каждый вариант может иметь различную информацию для каждого варианта. Когда продукт отображается на веб-странице, продукт 1 будет показан с раскрывающимся ящиком с малым & Medium. Продукт без вариантов, естественно, будет вставлять только 1 строку.

 
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 

Answer 1

Таблица ваших товаров шизофренична, ее сущность иногда является продуктом, а иногда и вариантом. Это приводит к очень громоздкому поведению. Например, вам нужен вопрос «сколько у нас разных продуктов?» ответьте select count(*) from products, но здесь это дает неправильный ответ, чтобы получить правильный ответ, вы должны знать Magic Number 0 и запрос select count (*) from products where master=0. «Список всех продуктов и сколько вариантов у нас есть для каждого» - это еще один запрос, который должен быть простым, но теперь это не так. Существуют и другие аномалии, такие как тот факт, что первая строка в описаниях продуктов - это рубашка с ценой и рисунком, но без размера (размер сохраняется в вариантах, но у них есть цены и собственные фотографии).

Ваша проблема в том, что у вас есть продукты в двух контекстах: (1) что-то, что можно отобразить как элемент в вашем магазине, и (2) что-то, что может быть заказано вашим клиентом. (1), вероятно, имеет название «Хэллоуинская футболка» или так, и у него, вероятно, есть изображение, которое видит клиент. (2) - это то, что заказывает клиент, поэтому он имеет (1), но также вариант спецификации, такой как «маленький» или, возможно, цвет «красный». Вероятно, у вас тоже есть цена и order_id, поэтому ваш магазин может узнать, какой конкретный товар отправлен.

Вы должны дать каждому контексту сущность. Вот как я бы это сделать

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 

Вы, вероятно, следует использовать locale вместо country в таблицах отображения для учета стран с более чем одним языком (США, Швейцария и другие), и вы можете отделить size и color в свою собственную таблицу variants. И если вам нужны данные, зависящие от страны, по заказу (например, разные цены/валюты для доставки в разные страны), вам также придется извлекать зависимую от страны таблицу orderable_content.