數據庫歸檔vs基於時間間隔的表/字段

Question

我正在開發一個員工目標Web應用程序。

負責人/經理在與他們討論之後爲團隊成員設定目標。這是一年一次/半年/季度，取決於組織遵循的評估週期。

現在問題是更好的方法來添加基於時間段的字段或存檔上一季度/年度的數據。當用戶想要查看先前的目標（不是那麼頻繁的活動）時，屬於該日期的檔​​案可以在某個臨時表中恢復並顯示給員工。

點開始與

歸檔：降低分貝的大小，在簡單的數據庫查詢的結果，增加了當有人試圖看到舊數據的開銷。

基於時間段的字段/表：查詢中的一個或多個額外連接，以前的數據被視爲與當前數據類似，因此在檢索舊數據時沒有開銷。

PS：這不是空間成本，我的觀點是如果我們可以在性能方面實現一些優化，因爲這是一個Web應用程序，並且在高峯時期，組織中的所有員工都會查看/更新它。所以刪除時間段使我的查詢變得更簡單。 謝謝

Answer 1

我會開始添加您的時間段字段，並等待，直到大小成爲一個問題。您所描述的數據類型聽起來不像將消耗大量存儲空間。

如果它無法控制地增長，您可以隨時查看歸檔方法 - 但編碼所花的時間要比簡單地將相關期間存儲在數據中要花費更多的時間。

Answer 2

在我看來，如果您有要求用戶在過去可以任意查看，那麼您確實必須保持數據的可訪問性。

這只是將是不可持續：

屬於該日期存檔在某些臨時表被恢復並顯示到員工。

我的建議是定期（絕對必要時讀取）爲此目的將「非常舊」的數據移動到另一個表中。現在磁盤空間非常便宜，因此保留這些數據並不像實施可以回到任意時間並恢復歸檔的系統那麼昂貴。

Answer 3

假設你正在討論隨時間變化的數據，而不是日誌類型的數據，那麼我的首選方法是隻在主表中保留數據的「最新」版本，並且自動將先前版本的數據複製到歸檔表中。這個歸檔表將鏡像主要的，增加版本字段，如時間戳。這種歸檔可以通過觸發來完成。

我用這種方法看到的主要好處是它不會危害您的數據庫設計。尤其是，您不必擔心使用包含版本字段的組合鍵（事實上，使用基於時間的字段作爲鍵甚至可能不會被數據庫所允許）。

如果您需要查看舊數據，可以針對歸檔表運行選擇並向查詢添加版本約束。