Схема базы данных для заказов, которые могут содержать настраиваемый продукт (RDMS)

Question

Я из прошлого, поэтому я прошу прощения, если этот вопрос о БД кажется глупым.

Скажем, у меня есть база данных, которая обрабатывает заказы автомобилей и автомобильных аксессуаров.Если Car не настраивается, то все просто.Для каждого заказа нам просто нужно связать OrderId с Car s ProductId.Но Car - это Product, который может содержать один или несколько Product, таких как навигация, обогрев сидений и т. Д. Кроме того, пользователи могут приобрести эти аксессуары Product отдельно.

Как мы должны это делатьЛучший?Если каждому Product пользовательскому заказу присваивается уникальный ProductOrderId в таблице заказов, и если этот Product может содержать еще один Product, то мы помещаем его в таблицу, которая связывает ProductOrderId с ProductId?

Если мы сделаем это, вырастет ли БД из-под контроля?Кажется, немного неэффективно для меня.Я чувствую, что есть лучший способ.

Answer 1

Если вы посмотрите, как обычно выставляются счета на сложные продукты, основной товар и каждый из его вариантов рассматриваются в отдельных позициях в накладной. В таком сценарии автомобиль - это продукт, и каждый из его аксессуаров также является продуктом. На product могут быть заштрихованные отношения, чтобы указать, какие аксессуары подходят к какому типу автомобилей.

Ваша модель данных для этого сценария будет выглядеть примерно так:

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