Проектирование реляционной базы данных: условные выражения - PullRequest
Новая
       10

Проектирование реляционной базы данных: условные выражения

0 голосов
/ 03 сентября 2018

Я проектирую реляционную базу данных, которую планирую реализовать с помощью SQL. У меня есть сценарий использования, над которым я работаю, и мне кажется, что у меня возникают проблемы с продумыванием решения. Дизайн для системы заказов электронной коммерции.

Вариант использования: Таблица ORDER_DETAILS содержит атрибут deliveryMethod. Затем у меня есть таблица SHIPPING_DETAILS, содержащая информацию об адресе, и таблица PICKUP_DETAILS, которая содержит информацию о местонахождении, дате и времени для личного пикапа. Когда пользователь размещает заказ, у него есть возможность отправить заказ на свой адрес или забрать свой заказ лично. Моя текущая мысль - иметь внешний ключ shippingId и внешний ключ pickupId в таблице ORDER_DETAILS. Затем, в основном, выполните условную проверку атрибута deliveryMethod и извлеките данные из соответствующей таблицы в зависимости от значения этого атрибута («доставка» или «получение»). С этой мыслью, однако, я бы позволил пустым значениям присутствовать в ORDER_DETAILS для атрибутов shippingId или pickupId. Насколько я понимаю, нулевые значения рассматриваются негативно в реляционных проектах. Поэтому я ищу отзывы об этом дизайне. Это нормально? Я переосмысливаю нули? Есть ли более эффективный способ разработки этой конкретной схемы?

1 Ответ

0 голосов
/ 03 сентября 2018

Если я правильно понимаю вашу проблему,

  1. Мощность отношения ЗАКАЗА к ДОСТАВКЕ составляет 1 ---> (0, 1)
  2. Кардинальность отношения ORDER к PICKUP равна 1 ---> (0, 1)
  3. ЗАКАЗ ДОЛЖЕН иметь либо ДОСТАВКУ, либо ПИКАП, но не оба.

Чтобы применить ограничение (# 3), вы можете определить функциональное ограничение в базе данных. Это входит в интересные вещи.

В любом случае, как вы говорите, вы можете сделать в ORDER столбцы, которые являются FK для таблиц SHIPPING или PICKUP, но оба из них могут иметь значение null. Я не думаю, что нулевые FK - это зло или что-то в этом роде, но они становятся грязными, особенно если у вас есть целая куча способов доставки, а не только два.

Если вам не нравятся пустые значения, вы можете иметь отдельные таблицы ассоциаций: (1) ORDER_DELIVERY, который имеет только order_id и delivery_id, каждый из которых является FK для соответствующих таблиц, и (2) ORDER_PICKUP, также с двумя столбцами Таблица. В каждом случае первичный ключ будет order_id. Теперь нет нулевых значений: заказы с доставкой находятся в таблице ORDER_DELIVERY, а заказы с доставкой - в ORDER_PICKUP.

Конечно, есть компромисс, поскольку поддержание ограничения на наличие только одного и только одного метода доставки не является проверкой согласованности между таблицами.

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

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

(О, ответ на вопрос «ты слишком много думаешь?» - нет, это мышление действительно хорошо!)

...