實體修訂架構設計

Question

SQL Server 2005.

在我們的應用程序中，我們有一個包含父表以及多個子表的實體。我們希望跟蹤對此實體進行的修改。來回之後，我們將其縮小爲兩種可供選擇的方法。

1. 有一個實體歷史表。在sproc更新表之前，從父表和所有子表中檢索整個實體的當前狀態。將其XML化並將其作爲XML數據類型粘貼到歷史記錄表中。包含一些要查詢的列，以及修訂號/創建日期。

2. 對於每個表，使用相同的列創建匹配歷史記錄表。還有一個修訂號/創建日期。在sproc更新單個表之前，檢索該表的記錄的現有狀態，並將其複製到歷史記錄表中。所以，它有點像SVN。如果我想在修訂版Y中獲取實體，我需要在每個表中獲取最大版本號不大於Y的歷史記錄。一個實體可能在一個表中有50個修訂記錄，但只有3個修訂記錄一個子表，等等。我可能想堅持整個實體的修訂計數器。

這兩種方法似乎都令他們頭疼，但我仍然更喜歡解決方案＃2解決方案＃1。這是一個已經很龐大的數據庫，並且已經遭遇性能問題。在每個修訂版中使用XML Blob來擴展它（並且會有很多）似乎是一種可怕的方式。爲所有事情創建歷史記錄表是我願意吃的成本，只要沒有更好的方法來做到這一點。

有什麼建議嗎？

感謝， Tedderz

Answer 1

2號幾乎可以肯定是要走的路，我做這樣的事情與我的歷史表，雖然我用一個「事件」表以及彼此相關聯的變化而不是使用時間戳。我想這就是你的意思是「修訂計數器」。我的「事件」表包含一個唯一的ID，一個時間戳（當然），負責更改的應用程序用戶和一個「動作」指示符，它表示用戶所做的導致更改發生的應用程序級動作。

爲什麼＃2？因爲您可以更容易地使用partition表格來歸檔或滾出舊條目。因爲索引更容易。因爲這是一個更容易查詢的整體。因爲它的開銷比XML少，而且要小很多。

另外，考慮使用觸發器而不是編碼存儲過程來完成所有這些。觸發器幾乎總是要避免的，但對於這樣的事情來說，它們是一種相當輕量級和強大的方式來執行這種事情。