状态表数据库设计

Question

我有四张表格如下：

装运

• ShipmentID（PK）
• OtherShipmentInfo

ShipmentStatus

• StatusID（PK）
• 状态说明

ShipmentStages

• ShipmentStageID（PK）
• ShipmentID（FK到货件）
• StatusID（FK到ShipmentStatus）
• 日期时间

DeliveryCodes

• DeliveryCodeID（PK）
• DeliveryCodeDescription

我的问题是哪个表格“更适合”存储与货件最终状态相关的信息？如果我只需要在最后一个发货阶段记录交货代码，我应该在ShipmentStages表中使用外键还是将外键放在Shipments表中并且只更新该外键最后阶段的关键？

由于DeliveryCode仅与最终出货状态相关，因此如果我将外键放在ShipmentStages表中，则大多数条目将具有NULL值。

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

Answer 1

三个选项：

1. 将您的状态和投放代码合并到一个表格中。如果货件有＆＃34; DeliveryCode＆＃34;状态，已经交付。实质上，交付状态将替换为所有可能的交付代码。 ShipmentStages仍然只需要对ShipmentStatuses的单个FK引用。 DeliveryCode表已删除。

2. 在ShipmentStages中使用FK参考向您的交货代码表添加N / A或待处理状态。尚未交付的任何货件状态将使用＆＃34;尚未交付＆＃34;交货代码。

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

----更新了评论----

分开装运阶段和交货不违反规范化。交货和装运阶段均描述装运，但交货不描述装运阶段。 3NF可能会要求在交货属性描述货件时将交货属性放入货运表中。您可以为交货捕获的属性不描述装运阶段，它们描述了一种类型的装运阶段。由于该阶段具有自己的唯一属性，因此可以将其分解为单独的实体。

如果数量/性能要求，将交付事件属性分离到它们自己的表中可以减少货件表上的CRUD负载以进行特定交付工作。另一种考虑方法是，如果您主要使用没有交货详细信息和/或没有货件详细信息的交货详细信息的货件表，则可以通过分离来获得收益。您可以通过将Delivery表使用Shipment表PK作为其自己的PK（1- [0,1]关系）来紧密地耦合它们。

如果您还没有性能问题，请从“发货”表中的交货代码开始。它总是可以在以后分开（虽然需要开发工作）。过早优化有时会浪费时间/金钱。