從資料層面來理解，資料可以分為幾個維度，比如流水型資料，狀態型資料庫，配置型資料。流水型資料的依賴最低，基本就是時間維度的擴充套件，所以從資料的安全形度來說，如果丟資料對業務的影響還是有限的，配置型資料是資料字典級別的，影響範圍更是小很多。關鍵的就是狀態型資料，這是非常核心的，因為只是標識狀態的變化，如果換做一個場景，比如是金額，那這個維度的影響是很大的。
從資料架構的角度來說，儘可能希望把一些狀態型資料的變化，通過流水資料的方式來做一個歷史沉澱，我們暫且成為歷史資料吧。
比如 更新狀態資料，餘額為200
Account_id, balance,effective_date, expire_date, status
100 100 20171004010100 20181104010200 1
可以改造為：
Account_id, balance,effective_date, expire_date, status
100 100 20171004010100 20171104010200 0 -->update語句
100 200 20171104010200 20181104010200 1 -->insert語句
所以顯而易見的，一個update被改造為了兩條語句，從資料生命週期來看，確實有了一定的保障，這也是我們需要和開發同學強調的一種設計方式。
然後我們看一下這種歷史資料的處理方案和想法。
一般來說，從設計的角度，儘可能是希望這樣來處理歷史資料的變化，即從程式層面來解讀這個資料的變化情況，可以包裝在一個事務裡，也可以根據需求來拆分成為非同步的方式。當然這種方式是一種看起來很自然的方式，其實也是一種相對來說最理想的方式，從我刻意來畫的圖來看，是強應用型的。
如果換一個角度來說，對於應用來說，歷史資料的生成對於他們是透明的，即他們不需要刻意關注這個邏輯，那麼這個邏輯就會下沉到資料庫層面，所以我畫的圖中，HIST的部分就會放大，這個邏輯如果在資料庫層面來處理，一種自然的方式就是儲存過程，當然會對應有一系列的邏輯處理，比如一類業務需要這些歷史資料的生成方式，其他類似的業務也是這種思路，那麼就需要有一種更加通用的方式，其實從資料庫層面來說，這種算是重系統層面的實現，因為資料庫層面如果繫結了這個邏輯，那麼如果來做擴充套件就是一個難題了。
還有一種方式，可能折衷一些，即程式可能下沉到資料處理層，資料庫處理層不用刻意去關係資料的意義，資料層可以做資料的寫入和流轉，可以通過程式層來包裝事務來生成歷史資料或者是透明的通過OLTP資料生成歷史資料，但是關鍵的一點是，歷史資料和OLTP的資料是放在一起的，當然這個表的資料會放大，所以我們需要做一種偏離線的資料歸檔，比如保留近7天的資料即可。而歷史資料可能保留有幾個月甚至幾年，這樣一來歷史的資料倒是可以實現分散式儲存，可能實際的意義和成本需要做平衡。
當然如果你有其他好的建議，也歡迎提出。