SQL數據庫中數據修訂控制的最佳實踐

Question

我的整個數據庫偶爾會有錯誤的條目，但我不想直接更改數據，而是希望能夠保留修改的更改。

這些變化很少發生。

理想情況是這樣的： -

 (original table fields) | revision_version | origin | user | timestamp

所以說我有一個名為posts的表，其中包含以下模式： -

title | description | timestamp | author

這樣就會創建一個名為posts_revisions的附加表： -

title | description | timestamp | author | revision_version | origin | user | timestamp

• 起源是變革的源泉，無論是機器人，用戶生成的還是你有什么。

您可以想象這是對現有數據庫的一個相當大的更改，我目前關注的是檢查每個查詢的_revisions表的性能。 對於這種事情，這是最好的做法嗎？

Answer 1

對於這種類型的問題，我保留了當前表和歷史表。

歷史記錄表具有以下附加列：

• HistoryID
• EFFECTIVEDATE
• 結束日期
• VERSIONNUMBER
• 由...制作
• CreatedAt

有效日期和結束日期是值有效的時間跨度。 每當記錄發生變化時，版本就會增加。 id，CreatedAt和CreatedBy是我幾乎放入數據庫中每個表的列。

通常，我會將歷史記錄表與夜間作業保持同步，比較表格然后使用MERGE組合數據。 另一種方法是將所有更改包裝在存儲過程中，並在那里更新兩個表。 另一種方法是使用觸發器來檢測何時發生更改。 但是，我回避觸發器，更喜歡前兩種選擇。

我必須承認磁盤空間不是這些表的重要考慮因素。 因此，存儲數據兩次沒有問題，一次在歷史記錄中的結果中一次。 僅在歷史表中存儲歷史記錄只是一個小調整，當前記錄在“當前”表中。

這種方法的一個缺點是改變基表的結構。 如果要添加列，則需要將其添加到歷史表和基表中。

Answer 2

如果這些表用於摘要目的（特別是業務用戶，如果他們有一些SQL訪問權限），我認為最好刪除數據並將其放入另一個表中。 雖然標志和修訂有時候很好，但是當你必須按照select sum(select someVar where revision_version=max(revision_version and someID=ID))它確實超出了簡單的范圍。

如果您有一個用於快速和討厭的數據收集的表，請替換數據，如果需要，將舊數據放入修訂表。 如果只有一些應用程序將訪問它並且它不是性能問題，那么將其保存在主表中。