Как хранить сложные данные о товарах/заказах в MySQL?

Я работаю над системой заказов для своего интернет-магазина. У меня есть 2 таблицы:

  1. продукты, хранение информации о продуктах
  2. заказы, хранение общих идентификаторов и информации о заказах клиентов.

Теперь я хочу иметь способ хранить сложные заказы клиентов в базе данных. Мне нужно что-то, что даст мне знать, сколько каждого размера (S, M или L) каждого продукта находится в заказе.

Сложность в том, что я хочу иметь возможность добавлять/редактировать/удалять продукты (конечно, не затрагивая заказы из прошлого), поэтому метод должен быть гибким.

Как мне это сделать?

  1. отдельная таблица для каждого заказа с продуктами в виде строк?
  2. одна таблица для всех заказов с продуктами в виде столбцов?
  3. какой-то другой вариант?

Спасибо!


mysql php sql database relational
person Community    schedule 04.12.2013    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Как минимум вам нужно:

Products (one row per product)
    ProductID
    Size

Orders (one row per order)
    OrderID

OrderDetails (one row per product per order)
    ProductID
    OrderID
    Size

Обратите внимание, что каждый «размер» — это собственный ProductID. Вы, вероятно, захотите иметь еще один идентификатор, который группирует продукты, которые являются одним и тем же «базовым» продуктом, но разных размеров.

Таким образом, если в заказе № 1 три продукта, а в заказе № 2 — четыре, то OrderDetails будет иметь семь строк:

OrderID ProductID Quantity
1       234       2
1       345       9
1       456       30
2       432       1
2       234       65
2       654       8
2       987       4
person egrunin    schedule 04.12.2013

arrow_upward
5
arrow_downward

Зависит от ваших целей для вашей корзины. Например, вы хотите разрешить гостевые покупки? т. е. где пользователю не нужно входить в систему, чтобы совершить покупку?

Прикрепленное изображение - это дизайн, над которым я работал, и он выглядит следующим образом:

  1. Посетитель выбирает товары на сайте и добавляет их в корзину сеанса (просто место для временного хранения товаров, их количества, цен и т. д.)

  2. Когда клиент готов оформить заказ, мы создаем заказ, ответственного за заказ и адрес person_address (куда должен быть доставлен товар) и добавляем товары в таблицу order_item. Вся эта информация добавляется покупателем на странице оформления заказа.

  3. Последним шагом будет предложение способов оплаты: PayPal, кредитная карта и т. д.

Что мне нравится в этом дизайне, так это то, что пользователи не обязаны регистрироваться у нас. Order_person действует как своего рода интерфейс между пользователями и заказами. Если зарегистрируемся, мы просто привяжем order_person к пользовательской таблице...

Я также включил образец внешнего интерфейса страницы оформления заказа.

Дизайн базы данных заказов товаров

введите здесь описание изображения

person HappyCoder    schedule 04.01.2015
comment
это было действительно полезно! одна маленькая вещь, которую я не понимаю, это что означает rbu_user_id? - person Philipp Mochine; 01.08.2018
comment
Хороший вопрос, также есть таблица пользователей (role_based_user), которая указывает на человека, ответственного за заказ (я должен был включить его для ясности). Когда пользователь регистрируется, он сохраняется в пользовательской таблице, а когда он совершает покупку, данные привязываются к его заказному_лицу (которое может варьироваться). Если кто-то решает не регистрироваться, его данные сохраняются в таблице лиц заказов. - person HappyCoder; 02.08.2018
comment
Существуют сценарии, в которых пользователь может инициировать платеж, отменить его и вернуться, чтобы попытаться отредактировать заказ, прежде чем перейти к следующему платежу. Если заказ, согласно вашему подходу, создается до завершения оплаты, как он редактируется? - person Alika Matthew; 25.05.2021
comment
Заказ необходимо создать, чтобы связать платеж с идентификатором заказа. Если пользователь хочет обновить заказ, создать новый заказ не составит большого труда... - person HappyCoder; 08.06.2021