以下状态表数据库设计

Question

我已经下面列出四个表：

出货

• ShipmentID（PK）
• OtherShipmentInfo

ShipmentStatus

• StatusID（PK）
• 状态说明

ShipmentStages

• ShipmentStageID（PK）
• ShipmentID（FK到出货）
• StatusID（FK到ShipmentStatus）
• DateTime

DeliveryCodes

• DeliveryCodeID（PK）
• DeliveryCodeDescription

我的问题是哪些表 “更合适” 来存储与货物的最终状态信息？如果仅在最终装运阶段时需要记录交货代码，我应该在ShipmentStages表中使用外键还是将外键置于Shipments表中，并且只在最后阶段时更新该外键？

因为DeliveryCode只与最终出货状态有关，所以如果我将外键放在ShipmentStages表中，则大多数条目将具有NULL值。

我觉得任何一种情况都会“起作用”，但哪一种更“合适”？

Answer 1

三个选项：

1. 结合您的状态和传送代码到一个表。如果货件具有“DeliveryCode”状态，则已交付。实质上，交付状态被替换为所有可能的交付代码。 ShipmentStages仍然只需要一个FK参考ShipmentStatuses。 DeliveryCode表被删除。

2. 在ShipmentStages中添加一个N/A或待定状态到带有FK参考的交货代码表。尚未交付的任何货件状态将使用“尚未交付”的交货代码。

3. 重新设计您的模型以将交付事件作为单独的实体进行捕获。这需要一个引用DeliveryCode和Shipmment表的表。这是最具扩展性和最不可能需要在未来重新设计的。

----更新了意见----

分离出货阶段和交付不违反正常化。交货和装运阶段都描述装运，但交货不描述装运阶段。 3NF可能会指示将交货属性放入装运表中，因为它们描述的是装运。您可能为交货而捕获的属性没有描述装运阶段，它们描述了一种类型的装运阶段。由于该阶段有其独特的属性，它可以分解成一个单独的实体。

如果数量/性能指示，将交付事件属性分隔到他们自己的表中可以减少装运表上的CRUD负载以用于特定交付工作。另一种考虑方法是，如果您主要使用没有配送详细信息和/或没有配送详细信息的配送详细信息的配送表，则可能会通过将其分开来获得收益。您可以通过让交货表使用货运表PK作为自己的PK（1- [0,1]关系）来紧密结合它们。

如果您还没有性能问题，请从货件表中的交货代码开始。它可以稍后分开（尽管开发工作将是必需的）。不成熟的优化有时会浪费时间/金钱。