Как правильно спроектировать БД услуги с изменяемой ценой в зависимости от выбранных опций?

Question

[Владислав]

Здравствуйте!

Подскажите, как правильно спроектировать БД под следующую задачу?

Есть цифровая услуга по работе с аудио, цена которой меняется в зависимости от выбора пользователем характеристик.
Если продолжительность аудио меньше 60 секунд, то идёт по цене 0, не зависимо от выбранных опций.
Если больше 60 сек. то за каждые 60 сек. определённая цена.
Плюс цена увеличивается за каждую выбранную опцию, так же поминутно.

Как это правильно реализовать? Через sku или ску в данном случае не подходит?

Answer 1

[Nik Faraday]

Причём тут это к проектированию БД? Если ваша цена зависит от чего-то там сверхъестественного, то это слой бизнес-логики, который будет высчитывать цену в зависимости от каких-то параметров. В БД вы эту информацию только храните и всё

Проектирование больше относится к тому, как правильно хранить данные и распределять между многими таблицами. Правильно спроектированная БД имеет своё отражение на объектах в используемом вами языке программирования, когда вы будете эти таблицы маппить в типы.

Всё что дальше, это уже бизнес-логика

UPD:
Для этой задачи SKU (артикулы) могут быть не совсем подходящим решением, поскольку у вас динамическое ценообразование. По таблицам будет примерно следующая ситуация (Накидал на коленках):

services:
 - id:uuid
 - name:varchar
 - description:varchar

options:
 - id:uuid
 - name:varchar
 - price:float

orders:
 - id:uuid
 - duration:integer
 - total_price:float
 - service_fk:uuid

order_options:
 - order_fk:uuid
 - option:fk:uuid

Comments

[Алексей Уколов]

Всё равно данные для бизнес-логики тоже надо где-то как-то хранить. Если хочется ими управлять через админку — то лучше всего в БД. Вот и проектирование образовалось :)
У автора цена как раз фиксированная, а вот стоимость меняется по определённой логике.

[Владислав]

Спасибо

Answer 2

[Алексей Уколов]

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

В целом для выбора наиболее подходящего решения нужно понимать требования и ограничения проекта.

Comments

[Владислав]

Спасибо за идеи.