在設計完 版本1的事件記錄表 後，大家就開始馬不停蹄寫**去新增事件記錄資料。
版本1：事件表
流水id
id物件id
obj_id
系統編碼
sys_code
網點編碼
area_code
操作者工號
operator_id
源狀態source_status
事件編碼
event_code
事件描述
event_desc
目標狀態
target_status
建立時間
create_time
123456
a111
test_system
***0123777
初始001列印列印完成2018-09-06 18:33:35
123457
a111
test_system
qqq0123666
列印完成002核銷核銷完成
2018-09-07 12:05:43
改進：
在記錄事件的源狀態statea時，一開始的做法是獲取其他業務資料表中某物件的當前狀態，來設定事件記錄表的源狀態。但在一些業務場景下，對於同乙個事件編碼event_code，雖然目標狀態stateb是一樣的，但是源狀態statea會有很多種情況，此時如果通過業務資料表的當前狀態來設定源狀態的值，會十分繁瑣，而且業務**上需要知道當前狀態，不夠透明。
基於上面情況，我們不再從其他業務資料表中獲取某物件的當前狀態，而是依賴於事件記錄表前後的資料，從版本1的表中，可看到，在按照建立時間排序的前提下，id為123457的源狀態（列印完成），就是上一條記錄id為123456的目標狀態（目標狀態）。所以想要設定某物件的源狀態，只要找到該物件在事件記錄表中的上一條記錄的目標狀態即可。
但這種方案，嚴重依賴於上一條記錄，當有多個節點同時都往這個事件記錄表插入資料時，要對這「上一條記錄」的資料進行鎖定，需要採用分布式鎖或者資料庫鎖的機制。
再次改進：
認真想想，由於事件記錄表是按照物件做動作時按時間順序插入的，只要保證時間順序，其實可以不需要記錄源狀態，每條資料的目標狀態，也相當於它上一條資料的源狀態。因此，我們對事件表進行改造，形成版本2：
版本2：事件表
流水id
id物件id
obj_id
系統編碼
sys_code
網點編碼
area_code
操作者工號
operator_id
事件編碼
event_code
事件描述
event_desc
目標狀態
target_status
建立時間
create_time
123456
a111
test_system
***0123777
001列印列印完成2018-09-06 18:33:35
123457
a111
test_system
qqq0123666
002核銷核銷完成
2018-09-07 12:05:43
由於事件記錄表本身的時間順序的特性，所以版本2的表基本可以滿足我們記錄物件全生命週期的需求。還是版本1的需求，比如我們想知道物件a111從列印完成狀態到核銷完成狀態所花費的時間，用sql更容易就實現了：
select create_time as begin_time from db_event_report where obj_id = 'a111' and target_status = '列印完成';select create_time as end_time from db_event_report where obj_id = 'a111' and target_status = '核銷完成';select timestampdiff(minute, begin_time, end_time);如何設計一張千萬級別的大表
1 資料的容量 1 3年內會大概多少條資料，每條資料大概多少位元組 2 資料項 是否有大字段，那些欄位的值是否經常被更新 3 資料查詢sql條件 哪些資料項的列名稱經常出現在where group by order by子句中等 4 資料更新類sql條件 有多少列經常出現update或delete ...
如何自行製作一張FreeBSDLiveCD
所謂livecd，就是指那種直接可以從光碟啟動，而無須安裝的作業系統光碟。這類光碟的主要用途包括 嘗試一種新的系統。由於不需要安裝，因此這樣做的風險要比直接安裝小的多。修復系統。freebsd早期版本的第二張光碟就是類似的livecd。本文將介紹如何通過freesbie製作freebsd的livec...
如何製作一張啟動卡
1.在linux下找到sd卡及讀卡器 cat proc partitions一般sd卡的裝置檔案節點是 dev sdb 2.刪除sd卡分割槽 sudo fdisk dev sdb command m for help 輸入 d，刪除所有分割槽，返回 selected partition 1 comm...