Проектирование базы данных - сложная ключевая проблема взаимоотношений

Question

Я уже публиковал похожий вопрос, но это более конкретно. Пожалуйста, взгляните на следующую диаграмму: Объяснение этого дизайна следующее:

• Пекари производят много продуктов
• Один и тот же продукт может быть произведен более чем одним пекарем
• Пекари время от времени меняют свои цены на определенные (свои) продукты
• Заказы могут быть созданы, но не обязательно завершены

Цель здесь - позволить менеджеру магазина создать «корзину» заказов на основе любых товаров, которые требуются, а также позволить создаваемой системе определить наилучшую цену в то время на основе того, какие продукты содержатся в заказе. .

Поэтому я предполагал, что таблица ProductOrders будет изначально содержать productID и связанный orderID, при этом поддерживая нулевое (неопределенное) значение для bakerID и pricingDate, поскольку это будет определяться и обновляться система, которая , затем будет составлять окончательный заказ.

Теперь, когда у вас есть представление о том, что я пытаюсь сделать, пожалуйста, посоветуйте мне, как лучше установить эти отношения.

Спасибо!

Answer 1

Если я правильно понимаю, незавершенному заказу еще не назначен пекарь / ценообразование (имеется в виду, что при размещении заказа еще не был выбран пекарь для выпечки продукта).

В этом случаеВозможно, заказ размещен в таблице «Продукты», а затем «завершен» в таблице «BakersProducts».

Решение может состоять в том, чтобы предоставить ProductsOrders 2 отдельные «ProductID's», один из которых предназначен для первоначально заказанного ProductId (т. е. не обнуляется)произнесите ProductId, а второй является частью внешнего ключа для назначенного BakersProducts (скажем, ProductId2).Это означает, что в ProductsOrders составные внешние ключи BakerId, ProductId2 и PricingDate имеют все значения NULL, поскольку они будут установлены только после завершения ордера.

Чтобы удалить эту избыточность, вы также можете использоватьсуррогатные ключи вместо составных ключей.Таким образом, BakersProducts будет иметь суррогатный PK (например, BakersProductId), который затем будет называться обнуляемым FK в ProductsOrders.Это также позволило бы избежать путаницы с Direct FK в ProductsOrders to Product.ProductId (который сверху был исходной линией Product как часть Заказа).

HTH?

Редактировать:

CREATE TABLE dbo.BakersProducts
(
  BakerProductId int identity(1,1) not null, -- New Surrogate PK here
  BakerId int not null,
  ProductId int not null,
  PricingDate datetime not null,
  Price money not null,
  StockLevel bigint not null,

  CONSTRAINT PK_BakerProducts PRIMARY KEY(BakerProductId),
  CONSTRAINT FK_BakerProductsProducts FOREIGN KEY(ProductId) REFERENCES dbo.Products(ProductId),
  CONSTRAINT FK_BakerProductsBaker FOREIGN KEY(BakerId) REFERENCES dbo.Bakers(BakerId),
  CONSTRAINT U_BakerProductsPrice UNIQUE(BakerId, ProductId, PricingDate) -- Unique Constraint mimicks the original PK for uniqueness ... could also use a unique index
)

CREATE TABLE dbo.ProductOrders
(
  OrderId INT NOT NULL,
  ProductId INT NOT NULL, -- This is the original Ordered Product set when order is created
  BakerProductId INT NULL, -- This is nullable and gets set when Order is finalised with a baker
  OrderQuantity BIGINT NOT NULL,


  CONSTRAINT FK_ProductsOrdersBakersProducts FOREIGN KEY(BakersProductId) REFERENCES dbo.BakersProducts(BakerProductId)
  .. Other Keys here
)