以下狀態表數據庫設計

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]關係）來緊密結合它們。

如果您還沒有性能問題，請從貨件表中的交貨代碼開始。它可以稍後分開（儘管開發工作將是必需的）。不成熟的優化有時會浪費時間/金錢。