Как создать архитектуру БД для заказов продуктов и услуг в приложений?

Question

[HCEL]

И так изначально были таблицы products и orders.
Таблица orders создавала платеж и меняла свой статус при успешной оплате продукта.

orders
id userId productId amount paid createdAt

Теперь появились такие вещи как "Покупка доп.услуг к продукту" это может быть Доставка, Оформление этого продукта и много разных вещей. Так же есть возможность купить VIP статус, которая будет предоставлять плюшки в приложений. Например бесплатная доставка и т д.

Как это можно спроектировать? Самое логичное что я пока придумал - это из таблицы orders убрать productId, потому что вдруг если что то добавится в приложений и собирать столбцы в бд типа (productId, productServiceId, serviceId) и ставить все по умоланию NULL не очень хорошая идея.

Мысль такая: таблицу orders оставить для создания глобальных платежей на сайте, а для каждого типа продукта создавать отдельную таблицу.
Например вот таблица заказов продуктов
product_orders
id productId orderId
Таблица заказов услуг для пользователей Вип статус, может подписки какие нибудь
user_service_orders
id serviceId orderId
и т д.

Comments

[Ипатьев]

Непонятно, раньше что ли можно было только один продукт купить? Два нельзя было?

[HCEL]

Ипатьев, можно. Просто таблица orders была напрямую связана с таблицей products. А сейчас кроме продуктов появились подписки в виде услуг такие как Вип-статус, которые нужно оплачивать отдельно. И создавать клон таблицы orders на service_orders, где заменится productId на serviceId кажется плохим решением.

[Ипатьев]

ну то есть под два продукта создавалось два заказа?
то есть фактически, в одном заказе можно было купить только один продукт?

[HCEL]

Ипатьев, В моем случае да.
Сейчас требуется все переделать под следующий пример - "Приложение интернет провайдера".
Там можно:
1. Купить оборудование Wifi роутер или TV приставка (Продукт);
2. Оплатить услугу сотрудника, который приедет к вам и подключит кабель к роутеру (Услуга);
3. Оплачивать ежемесячно тариф интернета (Услуга в виде тарифов).

Все эти пункты являются отдельными сущностями, которые оплачиваются, Фишка в том, что Вип-статус я покупаю отдельно, подписку оплачиваю тоже отдельно.

Answer 1

[Ипатьев]

У вас какой-то странный магазин был изначально.
Обычно делается две таблицы, orders и order_details, во вторую пишется состав заказа, в котором фиксируется цена, скидка и все такое прочее.
Доставка - это не дополнительная услуга, а отдельная сущность, привязанная к заказу, со своими заморочками.
Остальные доп. услуги - это обычные товары, которые кладутся в корзину.
Вип статус - плюшка пользователя, а не покупки. При оформлении заказа она просто учитывается при подсчете стоимости.

Comments

[HCEL]

Сейчас пытаюсь отдельный проектик написать с примера "Интернет-провайдер" и идей order_details тут получается что на каждый тип товара нужны разные столбцы деталей.

Попробую подробнее расписать:
Для деталей заказа Products понадобится: productId, count, attributeId, attributeValueId
Для деталей заказа Services понадобится: serviceId, dateRecieving (Дата предоставления услуги)
Для деталей заказа Tariffs (Тарифы пакетов интернета/TV): tariffId, dateStart(Дата начала услуги), dateEnd (Дата окончания услуги).

По такой логике получается мне нужно будет все таки сделать так:
order_products_details
order_services_details
order_tariffs_details ?

[Ипатьев]

у вас вообще не магазин получается. я плохо знаю предметную область провайдинга, но тут по-моему, всё другое.
товаров у вас получается всего десяток, еще столько же услуг
зачем нужна отдельная дата услуги - непонятно, ведь услугу оказывает мастер, который совершает выезд.
клиент не делает постоянно заказы, а у 99% будет только одна покупка.

Не знаю, я тут вообще не вижу нужды в таблице заказов. Есть пользователь, на нем висит тариф и какое-то оборудование. Но в целом повторюсь - я не знаю предметную область.

я только не понял тогда, при чем здесь упаковка и доставка.
Мне кажется, вам самому сначала надо определиться, что у вас за торговая точка.

Answer 2

[Константин Цветков]

Покупатель и Продукты и услуги.
Заказ и Спецификация заказа.