Best-Practices
處理架構更改的數據歸檔策略？
我正在使用一個擁有大約十年客戶數據的遺留應用程序。這些數據中的大部分未用於日常運營，但存在業務要求，在客戶從系統退休之前，這些數據可供客戶使用。
我們正在探索將數據存檔到現有數據庫的副本，然後在某個時間點之後從生產中清除記錄。
我擔心的是，由於開發工作，數據庫每個季度都會發生重大的架構更改。
如果我要歸檔數據的鏡像副本，我是否還需要應用每一個與生產不相符的更改腳本？
有沒有替代策略？似乎無論您選擇哪種儲存形式（即數據庫、平面文件、xml），您總是需要某種方式將舊模式映射到新模式。
在考慮解決方案之前，您需要更具體地定義您的需求：
- 為什麼需要歸檔？聽起來系統已經在處理舊數據了，那麼業務需要什麼來分離這些數據呢？表現？
- 存檔數據是只讀快照，還是可能更改歷史數據？如果可以更改，將支持哪些類型的更改（插入、更新、刪除或它們的某種組合）？
- 數據庫是否是多租戶的，如果是，您是否要求每個租戶能夠在不同的時間點進行歸檔？
- 您的應用程序是否需要以歸檔數據作為數據源執行？我假設是的，因為您提到同步架構更改。
- 您需要支持的 DBMS 的最低版本/版本是多少？這將確定哪些功能可用於您的策略。
- 您有多少時間來實施歸檔？歸檔是一個非常底層的設計問題，理想情況下應該從一開始就做好；稍後添加它可能需要大量時間來重新設計和實施。
說了這麼多，我會建議你的一件事是：如果可能的話，避免使用多個數據庫，特別是如果你需要編輯歷史數據的能力。
- 雖然我不能透露我們的 IP，但我會告訴您，如果您採用像我們對約 700 個表所做的動態方法，將數據從“實時”數據庫轉移到“存檔”數據庫的過程非常複雜. 根據您的數據庫模式的狀態，這種事情甚至可能無法完成，或者導致您不期望的數據差異。如果您沒有很多表（< 200）並且架構處於粗糙狀態，老實說，不要採用動態方法，或者等到它被清理到一個體面的狀態。使用大量表和粗略的模式，多個數據庫不是一個可行的解決方案。
- 正如您所提到的，您確實必須針對多個數據庫執行更新腳本，並且您必須以某種方式跟踪所有數據庫。事情變得不同步真的很容易，例如，存檔數據庫被移動到不同的伺服器或實例，而您的配置數據庫或表保存舊資訊。選擇要麼始終同步模式，要麼將應用程序編寫為始終向後兼容。（提示：同步模式要容易得多。）
雖然我當然不推薦多個數據庫，但根據您的要求，這是一種可能的解決方案。