關系數據庫：當前數據與歷史數據，最佳實踐

Question

我們來看一個關系數據庫，例如MySQL。 為了簡單起見，我將集中精力處理重要的事情：擁有一個包含訂單的表，其中包含order_id （主鍵） order_date和外鍵fk_supplier等字段，它們引用表supplier的主鍵。 該表還有一個名為supplier_name的字段。 現在，讓我們想象一下，有一個php網站顯示了在表格中生成的所有訂單。 該表的每一行由order_id ， order_date和supplier_name組成（sql語句在兩個表上建立了連接）。 到目前為止一切都還好。 現在，有人更改了其中一個訂單中引用的一個供應商的名稱：歷史數據變得不真實或錯誤。 我的問題是：為了防止這種情況，最佳做法是什么？ 我想到了三種解決方案：

1. 不要讓用戶更改訂單中引用的供應商數據行。 如果名稱更改，請讓他添加新供應商。
2. 始終使用訂單記錄保存當前供應商數據（例如供應商名稱），不要使用主鍵/外鍵引用。
3. 引入時間片：每次更改供應商（如名稱）的重要屬性時，都會創建新的時間片。 不僅可以參考訂單中的supplier_id，還可以參考相應的時間片。

所有這些方法都有優點和缺點。 例如，點2似乎非常臟，並且違反了關系數據庫的所有規則。 在我看來，第3點通常是要走的路。 但需要付出很多努力，編程明智。 用戶體驗/可用性也非常糟糕。

我想知道，經驗豐富的開發人員和數據庫設計人員如何處理這個問題。

Answer 1

選項3的一種形式，其中有關於供應商信息的StartDate和EndDate。 這樣，數據在所有時間都是准確的（供應商名稱在給定時間是正確的）。 您還可以做的一件事是創建一個電子表格，其內容每晚都會加載到具有Supplier信息的數據庫中（到fact_Supplier表或查找表中）。 對供應商的所有編輯都要通過此電子表格，只有那些負責此類事情的精選人員才能訪問。 如果電子表格中有更改，則“供應商”表中的先前信息將結束日期，並且新記錄將隨新信息一起插入。 任何改變都會發生這種情況，供應商名稱，供應商地址等。

Answer 2

將擴展我的評論：

我會選擇選項2，但稍作修改：

• 供應商表應保持原樣。
• 訂單表應該繼續引用供應商表
• 創建新表，例如OrderInvoiceDetails，它與Order表有1對1的關系，與供應商有FK。 該表將包含供應商詳細信息的快照。

優點：

• 輕松高效的查詢
• 如果需要，可以與“供應商”表單獨修改發票詳細信息。
• 我認為這是最好的解決方案，因為您希望存儲與特定訂單相關的供應商詳細信息，而不是存儲供應商歷史數據。
• 舊數據可以與訂單數據一起輕松存檔

缺點：

• 存儲冗余數據，尤其是對於細節不經常更改的供應商