使用外鍵或保存交易歷史信息的數據？

您有一個銷售給客戶的電子商務網站。有些交易顯然是例如對於每筆銷售，您都記錄有關銷售的信息。所以讓我們有一個'採購'表。它應該包含哪些列？

1）它是否應該使用'customer_id'爲'customer'表創建一個外鍵？ OR 2）保持的快照，如 'CUSTOMER_NAME'， 'customer_address' ...既作爲VARCHAR（x）的 OR 3）BOTH OR 4） '購買' 表分成多個表？或別的東西。

請給出您的意見和原因。歡呼

2012-04-20 edster

如果時間是你的問題域的固有概念 - 與電子商務，它是 - 你應該把這個作爲你的架構一流的設計理念，太。

我的最佳選擇是對可以隨時間變化表一個「有效期」的指標。舉例來說，這裏是客戶表可能是什麼樣子：

CUSTOMER 
--------------- 
CustomerID pk 
RecordVersion pk 
Name 
EmailAddress 
HomeAddressID fk 
HomeAddressRecordVersion fk 
ValidFrom 
ValidUntil

的「購買」表，然後通過指定雙方在客戶和RecordVersion列連接到客戶表。這樣，如果您想查看客戶在下訂單時使用的電子郵件地址，則可以從客戶表中檢索該數據。

您會知道客戶使用的其他電子郵件地址，這不僅僅是因爲您可以在某些購買數據中找到該地址，而是因爲它是您客戶記錄的一部分。

此模型可能會變得相當複雜，而且很難查詢 - 所以請謹慎使用它。但特別是對於產品，價格，折扣，交貨地址等，這是非常有用的。在電子商務解決方案中。

2012-04-20 12:09:08

與存儲快照相比，此方法聽起來不錯。它確實保持了相關數據的時間維度。我想，就像你說的那樣，查詢將變得更加複雜，並且應該考慮創建一個函數庫，在一個集中的位置爲你做這些。乾杯 – edster 2012-04-21 23:35:26

關於列的採購表應該有它在很大程度上取決於你的需求。通常情況下，您需要某種購買代碼，購買日期和購買客戶作爲最低限額，以及購買中的項目清單（單獨的表格）。

關於你提到的選項，我猜你在這裏有一個關係數據庫，並沒有去找NoSQL解決方案。

在這種情況下，我會放棄選項（2）。它不適合於關係模式，因爲您可能會在多個記錄中複製客戶信息。出於同樣的原因，我也會放棄選項（3）。

選項（1）更適合用於關係數據庫方法。你會購買，他們每個人都鏈接到自己的客戶。這使您可以輕鬆地知道：

如果您需要能夠記錄在給定日期的客戶數據，你總是可以選擇創建一個客戶歷史表，並將其鏈接到客戶表。考慮到購買日期，您可以瞭解在購買時哪些客戶數據是「活躍的」。

關於選項（4），我不知道你的意思，所以我不能回答這個問題的。

HTH

2012-04-20 11:56:41

回答