需求場景：某些資料表的歷史資料會做更新，客戶那邊做回測需要那個時間段對應的資料。
基本解決方案：
1.資料表中增加字段，記錄資料的變動情況（增加資料版本字段），這種解決方案只能解決固定更新次數的資料。
2.利用觸發器/cdc（基於sqlserver）捕獲變化後固化到固定的表，這樣操作的優點是資料完整，可以直接從history表查出來，缺點是觸發器會影響資料寫入的效率（大批量資料變更的時候還可能引起堵塞）；cdc效率比觸發器好，但是不能永久的儲存資料，需要做固化。這兩個方案還有個缺點，就是資料會存在大量的冗餘，占用大量的磁碟空間，當源表字段變更的時候history表的字段也要做相應的變更。
3.利用數倉的歷史拉鍊表，記錄每一行的生命週期。這個方案的優點是資料冗餘會比較小，但是表的結構要做調整。
個人思考：
1.變數：
（1）實現需求；
（2）對錶結構的改動最小
（3）效率高
（4）對後面資料的維護流程影響小
（5）占用磁碟空間小
（6）其他問題：真更新/假更新（欄位某一列字段變更，增加字段，資料庫後台批量操作帶來的資料變化，不是真正源資料的變化）
2.實現方式：
（1）我們這邊大boss給的建議是讓開發在前端程式中實現，這樣能避免變數6的問題，但是資料入口一定要管嚴，各個資料入口都要能做到記錄資料變化。這樣做能減少資料庫的維護，避免業務需求下沉到資料實現。
（2）個人認為如果非要用資料來做，可以用歷史拉鍊表的優化方式來做，當然前提也是要區分場景的。
s1.分析/提取資料行經常變化的關鍵字段
s2.建立子表，存放該關鍵字段的版本，在表中存放關聯key、字段值、起始生效時間、結束生效時間。
查詢可以通過函式來做，修改欄位的時候修改子表即可。這樣原表的唯一約束也可以保留不做修改。
個人看法，歡迎拍磚。
資料庫時間段合併
資料庫時間段合併 專案中遇到乙個有意思的業務需求，涉及到時間區間的合併與拆分 簡化描述一下 假定系統中有兩類使用者 甲方，暫稱債務人 乙方，暫稱為債權人 債務人和債權人之間可以生成許多實體物件 若當債務人與指定的債權人簽訂協議後，就意味著雙方存在了關係，此時就要求對關係雙方的實體物件打上標記，標記分...
MySQL資料庫獲取一段日期內某個時間段
前一段時間在專案中需要查詢乙個月內乙個時間點到另乙個時間點的資料，剛開始真的是沒有什麼頭緒，然後就在晚上開始找，最後找到了乙個mysql資料庫中自帶的函式date format然後就有了如下的 查詢本月8點之前的番茄總數量 使用者id public int selecteight string us...
SQLite資料庫的時間和時間段操作
sqlite資料庫的時間和時間段操作 sqlite資料庫，日期的字段是char。也許設定為別的資料型別更好一些。內容格式為 yyyymmdd，比如 20171230，表示2017年12月30日。查詢某一天 select from table name where date like 20171230...