Должен ли я просто использовать одну таблицу? - PullRequest
Новая
       33

Должен ли я просто использовать одну таблицу?

1 голос
/ 01 октября 2011

У меня есть сущность Order.

В заказе есть информация о дате, клиенте, сотруднике, который обработал заказ и т. Д.

Теперь заказ также должен хранить состояние, то есть различать выигранные заказы и потерянные заказы.

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

(Что касается информации о домене, то заказ не состоит из элементов. Это сервисная компания, которая пытается обрабатывать клиентов и делает предложения о том, когда они могут доставить заказ, по какой цене и т. Д.). Таким образом, клиент может найти более выгодный выполнить резервное копирование и остановить процесс заказа у компании).

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

У меня вопрос, что было бы лучшим представлением Order?

Я думал об использовании одной таблицы и просто получил за выигранные ордера ReasonLost как ноль.

Имеет ли смысл создавать отдельные таблицы для WonOrder и LostOrder, если разница между этими новыми объектами незначительна?

Какая модель лучше всего подойдет для этого случая?

Ответы [ 2 ]

2 голосов
/ 01 октября 2011

Используйте одну таблицу.Добавьте поле OrderState.

Предупреждение: если вы выполняете миллионы транзакций в день, подобные решения требуют гораздо большего внимания и анализа.

1 голос
/ 02 октября 2011

Существует еще один альтернативный дизайн, который вы могли бы рассмотреть.В этой альтернативе вы сохраняете вторую таблицу для причины потери заказа и связываете ее с таблицей заказов как необязательное значение 1: 1.Обратите внимание, что это фактически реализация шаблона супертипа / подтипа, где подтип потерянного порядка имеет один дополнительный атрибут.

Это выглядит так:

ERD

Альтернатива может быть привлекательной при любом из следующих обстоятельств:

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