設計數據歸檔的過程（SQL Server 2005中）

Question

我們正在設計過程中存檔的一套基於如日期，狀態等不同條件的記錄...

組簡化表：Claim, ClaimDetails, StatusHistory（跟蹤要求狀態的變化），Comments & Files

環境： SQL Server 2005中，ASP.Net MVC（.NET框架V3.5 SP1）

Claim是主要實體，它在子表中提到了子行。有些具有細節，其他細節用於追蹤更改。最終根據一些標準，Claim成爲「準備存檔」，如上所述。簡單地說，歸檔的Claims將從數據庫中識別出來，並在網絡應用程序中以不同的方式處理。

這裏有一個簡單的版本：（俯視圖）

• 創建一個腳本，這標誌着一個以dB爲Claim 「存檔」。
• 存檔行及其子行可以保存在同一個表中（設置標誌）或移動到不同的表中，該表將成爲原始表的副本。
• 在網絡應用程序中，我們將根據存檔狀態讓用戶過濾Claims。
• 將來可能需要「解除」Claim。

我需要知道什麼？

1. 我們需要保持這種簡單和容易儘可能並靈活地適應未來的變化 - 請建議的方法。

2. 適時的預定SQL腳本是此場景的最佳選擇嗎？

3. 我應該考慮使用單獨的表還是隻爲每個表添加「存檔」標誌？

4. 對於選定方法的性能考慮 - 如果我們打算擁有大約10,000個Claims以及如果它有100萬個，會有什麼不同？總之請提供一個輕載&重載方法。

5. 我們存儲在我們的服務器上物理上傳的文件 - 我相信這樣可以保持原樣。

注：聲明可以在所有提到的表任意數量的子結果，因此它獲得正折。

是否有一個標準的框架，或者說我應該是指了解歸檔進程模式。任何樣品參考文章或工具將幫助我瞭解更多。

Answer 1

您可以找到關於此主題的一些優秀的討論here和this是另一個。

將單獨表格中的歸檔數據賦予更大的靈活性，就像您要追蹤標記爲已歸檔的索賠的用戶或歸檔索賠的日期，或在創建索賠後查看對索賠所做的所有更改一樣。