在資料倉儲的資料模型設計過程中，經常會遇到這樣的需求：
1. 資料量比較大;
2. 表中的部分欄位會被update,如使用者的位址，產品的描述資訊，訂單的狀態等等;
3. 需要檢視某乙個時間點或者時間段的歷史快照資訊，比如，檢視某乙個訂單在歷史某乙個時間點的狀態，
比如，檢視某乙個使用者在過去某一段時間內，更新過幾次等等;
4. 變化的比例和頻率不是很大，比如，總共有1000萬的會員，每天新增和發生變化的有10萬左右;
5. 如果對這邊表每天都保留乙份全量，那麼每次全量中會儲存很多不變的資訊，對儲存是極大的浪費;
拉鍊歷史表，既能滿足反應資料的歷史狀態，又可以最大程度的節省儲存;
舉個簡單例子，比如有一張訂單表,6月20號有3條記錄：
到6月21日，表中有5條記錄：
到6月22日，表中有6條記錄：
資料倉儲中對該錶的保留方法：
1. 只保留乙份全量，則資料和6月22日的記錄一樣，如果需要檢視6月21日訂單001的狀態，則無法滿足；
2. 每天都保留乙份全量，則資料倉儲中的該錶共有14條記錄，但好多記錄都是重複儲存，沒有任務變化，如訂單002,004，資料量大了，會造成很大的儲存浪費；
如果在資料倉儲中設計成歷史拉鍊表儲存該錶，則會有下面這樣一張表：
說明：1. dw_begin_date表示該條記錄的生命週期開始時間，dw_end_date表示該條記錄的生命週期結束時間；
2. dw_end_date = '9999-12-31'表示該條記錄目前處於有效狀態；
3. 如果查詢當前所有有效的記錄，則select * from order_his where dw_end_date = '9999-12-31'
4. 如果查詢2012-06-21的歷史快照，則select * from order_his where dw_begin_date <= '2012-06-21' and end_date >= '2012-06-21'，這條語句會查詢到以下記錄：
和源表在6月21日的記錄完全一致：
可以看出，這樣的歷史拉鍊表，既能滿足對歷史資料的需求，又能很大程度的節省儲存資源。
拉鍊式儲存 極限儲存之拉鍊表
在資料倉儲的資料模型設計過程中，經常會遇到這樣的需求 1.資料量比較大 2.表中的部分欄位會被update,如使用者的位址，產品的描述資訊，訂單的狀態等等 3.需要檢視某乙個時間點或者時間段的歷史快照資訊，比如，檢視某乙個訂單在歷史某乙個時間點的狀態，比如，檢視某乙個使用者在過去某一段時間內，更新過...
資料倉儲資料模型之 極限儲存 歷史拉鍊表
在資料倉儲的資料模型設計過程中，經常會遇到這樣的需求 1.資料量比較大 2.表中的部分欄位會被update,如使用者的位址，產品的描述資訊，訂單的狀態等等 3.需要檢視某乙個時間點或者時間段的歷史快照資訊 比如，檢視某乙個訂單在歷史某乙個時間點的狀態，比如，檢視某乙個使用者在過去某一段時間內，更新過...
資料倉儲資料模型之 極限儲存 歷史拉鍊表
在資料倉儲的資料模型設計過程中，經常會遇到這樣的需求 1.資料量比較大 2.表中的部分欄位會被update,如使用者的位址，產品的描述資訊，訂單的狀態等等 3.需要檢視某乙個時間點或者時間段的歷史快照資訊，比如，檢視某乙個訂單在歷史某乙個時間點的狀態，比如，檢視某乙個使用者在過去某一段時間內，更新過...