Какое проектирование БД более верное?

Question

[AndreyAndreevTM]

Есть 3 таблицы:

• Products
  
• Categories
  
• Discounts
  

Каждый продукт (Product) связан с одной категорией (category_id => id). Здесь всё понятно.
Каждая скидка (Discount) связана с одним или несколькими продуктами, с одной или несколькими категориями.

Вопрос: как их связать и где можно прочесть о шаблонах построения структуры БД?

Answer 1

[Decadal]

Discounts нужно связать двумя "многие-ко-многим", это делается при помощи двух вспомогательных таблиц. Таким образом, у вас один Discount может
1) не иметь связи ни с товаром ни с категорией
2) быть связанным с множеством товаров
3) быть связанным с множеством категорий
4) быть связанным как с несколькими товарами, так и с несколькими категориями

Comments

[Сергей Семенко]

Можете сказать, каким софтом создаются такие схемы? Прям идеальная схема получилась.

[Decadal]

Сергей Семенко ondras.zarovi.cz/sql/demo
генерация mysql тоже есть, только нужно дописывать вручную onupdate ondelete к FK, и id по умолчанию почему-то nullable.
есть ещё приложение MySQL Workbench (даже на linux), но я имел несчастье познакомиться с ним позже чем с sql/demo, поэтому W показался мне сложноватым

[Сергей Семенко]

Decadal: спасибо

[Максим Тимофеев]

Я предложил то же самое, но советую как у меня в схеме добавлять id к каждой таблице, что бы PK был абстракцией

[Decadal]

Максим Тимофеев PK как абстракция - для AR модели? Я делал развязки многие ко многим присваивая PK двум полям с айдишниками, чтобы гарантировать, что связка не повторится и будет уникальной (на схеме PK выделены жирным). Можете подробнее про абстрагирование PK?

[Максим Тимофеев]

Decadal: product_id и id_discount - это определенные сущности, да их комбинация уникальна и это будет хорошо работать, но это имеет подводный камень. Например в дальнейшем при развитии проекта придется удалить, переименовать product_id например или добавить еще что-то. А так как product_id не абстракция для данной таблице, а связующее звено - это будет проблемой. Поэтому рекомендуется добавить id. id которое будет PK и будет автоинкремент. С этим проще работать. Удалять по id, сортировать по id и т.д. Менять структуру таблицы. Это не обязательно в данном конкретном случае, но крайне удобно и дает уверенность в отсутствии гемороя в будущем.

[Decadal]

Максим Тимофеев понял, спасибо что обратили моё внимание на это

Answer 2

[Максим Тимофеев]

таблиц должно быть больше
Products
Categories
Discounts
Discounts_Products ( id | discount_id | product_id )
Discounts_Categories ( id | discount_id | categories_id)

Доки для связи через другую таблицу:
www.yiiframework.com/doc-2.0/guide-db-active-recor...
(искать "Relations via a Junction Table")

как вариант последние две можно заменить на 1, но по опыту геморойнее:
так d_p_c ( id | discount_id | product_id | category_id)
или даже так ( id | discount_id | related_item_id | related_item_classname)

Answer 3

[d-stream]

Кстати стоит иметь в виду, что в реальной жизни зачастую "скидка на скидку" неприменимо.
Посему лучше заблаговременно подойти к "правилам скидок".

Как один из вариантов:
1. таблица групп(категорий) скидок rules_groups (id, descr, [ordering])
2. таблица "правил применения скидок" rules(id, group_id, descr, ordering, percent [условия])

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

select top 1 percent from rules where group_id=xx and (кучка условий на соответствие правилу) ORDER BY ordering

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

По вкусу можно на уровне групп или правил предусмотреть признак мультипликативная (умножение на коэффициент) это скидка или аддитивная (вычитание суммы) и "за единицу" или "за партию".
Ну и с учетом танцев с финокруглениями на тему НДС - неплохо иметь признак "С НДС"/"Без НДС" (но это подразумевает ньюансы хранения цен.

Еще элементом тюнинга будут флаги или коэффиценты на предмет применять ли правило при снижении отпускной цены ниже себестоимости"