Дисконтная UML диаграмма

Question

Я хотел бы знать, как это сделать в моей базе данных.Поэтому я попытался сделать UML-биграмму.

Но мне все равно не удалось это сделать.Мне не нужно делать диаграмму UML.Просто я не знаю, как сделать эту ситуацию в базе данных.

Моя ситуация:

Я хотел бы управлять скидкой на своем веб-сайте.Скидка выглядит следующим образом: У вас есть скидка с:

1. начала и
2. даты окончания

Вы можете получить скидку в виде процентной ставки или абсолютную скидку (пример -20% или -10 €).

Скидка предоставляется на:

1. Продукт (один ко многим) (только конкретный продукт, например: product_id: 21)
2. заказ (один ко многим) (по полному заказу, поэтому общее количество всех продуктов, ex_id_id: 33)
3. продукт с определенным поставщиком (один для многих) (ex provider_id: 12)
4. только для одного или X клиентов (один ко многим) (например: customer_id: 12 и customer_id: 24)

Проблема в том, что у меня 3 таблицы с одной и той же «промежуточной таблицей» с почти одинаковыми атрибутами ... Я не знаю, как это упростить ...

Answer 1

Вариантов немного, у каждого есть свои преимущества и недостатки.То, как вы это разработали, определенно является одним из возможных подходов.Преимущество заключается в том, что вы полностью используете родные технологии БД (особенно FK).Недостаток в том, что у вас получается сложный дизайн.

Другой вариант, который мне приходит в голову, это то, что вы можете построить только один объединяющий стол in_promotion с тремя атрибутами:

+fk_id_promotion : integer
+fk_id_prmotionRecipient : string
+promotionRecipientType

Второй на самом деле не настоящий ФК в понимании БД.С другой стороны, последний, вероятно, будет также FK для какого-то словаря, но я пропущу это на мгновение.

В этом подходе вы смешиваете FK для разных таблиц, в зависимости от типа, указанного в promoRecipientType.Вместо четырех таблиц у вас есть одна.

Преимущество такого подхода состоит в том, что вам легче следовать модели (до некоторой степени!), Но в итоге вы получаете решение, которое является менее эффективным (вы не можете простоВ случае таблиц вам необходимо читать эту информацию по отдельности и объединять ее на уровне приложения.Другим существенным недостатком является то, что он ограничивает ваш выбор типов ПК - они должны быть одинаковыми во всех таблицах для объектов, подлежащих повышению.

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

Со временем вы 'Вы узнаете, как лучше всего работать в конкретном случае.