關系數據庫設計：條件

Question

我正在設計一個我計划用 SQL 實現的關系數據庫。 我有一個正在處理的用例，似乎在思考解決方案時遇到了一些麻煩。 該設計用於電子商務訂單系統。

用例： ORDER_DETAILS表包含一個deliveryMethod屬性。 然后我有一個包含地址信息的SHIPPING_DETAILS表和一個包含地點、日期和時間信息的PICKUP_DETAILS表，以便親自取貨。 當用戶下訂單時，他們可以選擇將訂單運送到他們的地址或親自取貨。 我目前的想法是在ORDER_DETAILS表中有一個shippingId外鍵和pickupId外鍵。 然后，基本上對deliveryMethod屬性運行條件檢查，並根據該屬性的值（“shipping”或“pickup”）從適當的表中檢索數據。 然而，有了這個想法，我將允許在ORDER_DETAILS為shippingId或pickupId屬性提供空值。 根據我的理解，在關系設計中，空值被認為是負面的。 所以我正在尋找有關此設計的一些反饋。 這個可以嗎？ 我是否過度考慮空值？ 有沒有更有效的方法來設計這個特定的模式？

Answer 1

如果我正確理解你的問題，

1. ORDER 與 SHIPPING 關系的基數是 1 ---> (0, 1)
2. ORDER 與 PICKUP 關系的基數為 1 ---> (0, 1)
3. 訂單必須有 SHIPPING 或 PICKUP，但不能同時有。

要強制執行約束 (#3)，您可以在數據庫中定義一個功能約束。 這進入了有趣的事情。

無論如何，就像您說的那樣，您可以在 ORDER 中創建列，這些列是 SHIPPING 或 PICKUP 表的 FK，但它們都是可為空的。 我不認為空 FK 是邪惡的或任何東西，但它們確實會變得混亂，特別是如果你有一大堆交付方法而不是兩個。

如果你不喜歡空值，你可以有單獨的關聯表：(1) ORDER_DELIVERY 只有一個 order_id 和一個 delivery_id，每個都是各自表的 FK，以及 (2) ORDER_PICKUP，也是一個兩列表。 在每種情況下，主鍵都是order_id 。 現在沒有空值：帶交貨的訂單在 ORDER_DELIVERY 表中，帶取貨的訂單在 ORDER_PICKUP 中。

當然有一個權衡，因為維護只有一種且只有一種交付方法的約束不是跨表的一致性檢查。

另一個想法是使交貨和取貨詳細信息成為 JSON 字段。 在這里，您在應用程序方面做了更多工作，以編程方式強制執行約束，但您不會有空值。

我希望我能說這里有一個灌籃高手的設計模式，但我沒有看到。 就個人而言，只有兩種類型的交付方法，我不會回避空值（因為我不是純粹主義者）。 但是當數據庫完成工作時我確實喜歡它，所以......

（哦，“你是不是想多了？”這個問題的答案是否定的，這個想的真好！）