好久沒來寫東西了，正好最近碰到個說大不大說小的需求，和大家分享下，如果有什麼更好的方案也請告訴我
需求：現在佣金為固定的。將來要針對不同的平台，不同的場景，不同的理財師角色，配置不同的佣金係數、發放形式
整體設計：
根據需求，最終決定將佣金配置分為三部分：基礎佣金、活動佣金、轉讓佣金。同乙份佣金計算及發放**，迴圈三次。
轉讓佣金是全域性控制，和基礎佣金及活動佣金與標或專案有關不同，必須獨立。
且不建議把基礎佣金與活動佣金合併在一起。基礎佣金調整頻度很小，活動佣金會根據活動時間，活動情況調整，甚至同一天內不同標的佣金都不同，調整頻繁。
如果合在一起，從記錄的角度還是賬務的角度，資訊都不夠清晰，會很混亂。拆分後，資金情況很清楚，這部分是基礎佣金，這部分是活動佣金。
配置的修改的實現：
需求方希望，佣金配置的修改不影響已關聯的標。
方案一：
在標資訊的表中新增多個字段，記錄當時的配置，記錄每個角色對應的佣金。
方案二：
標相關表新增兩個字段，存放配置id與配置版本號。在配置表中，id與「版本號」為聯合主鍵，修改某規則後，新增版本號
方案三：
標相關表僅新增「配置id」字段。配置表不涉及版本號。當有標與該配置繫結時，該配置不可修改。可以直接新增
方案一明顯是最不合適的。因為資料庫中冗餘資料太多，且不具有擴充套件性。增加角色的話，方案二，三隻需改動配置表的表結果，而方案一缺需要改動標的表結構，不可取
最終選擇方案三，因為從邏輯上說，使用版本號修改某個配置和新增配置沒有本質區別，那就選用簡單的方式。
不斷新增，會不會導致發標時候，配置的下拉列表很長？不會，因為有配置停用的功能。停用後不在下拉列表中展示。
轉讓配置的實現：
轉讓佣金配置，除了涉及各角色不同的佣金係數。還和轉讓產品的還款方式（一次性還本付息、等額本息）、可轉讓天數（30天可轉、60天可轉、90天可轉）以及活動時間有關。
難點倒並不是在佣金的計算，而是在配置規則的新增。要保證不衝突，乙個轉讓產品在計算佣金係數時，只有一條規則匹配成功。
方案一：
乙個活動配置（比如30,60天可轉的等額本息專案）在資料庫中按多條儲存，每行乙個角色。優點：直接sql語句判斷是否有規則衝突。缺點：配置編輯時可能還需要刪資料，不方便（因為只有未使用，才容許編輯，所以可以直接刪）
方案二：
方案一、二都不是太理想，將兩者合併一下，公升級為
最終方案：
乙個活動配置在資料庫中按一條存放。可轉天數以及還款方式分別以bitmap形式（假設30天可轉為1,60天可轉為2,90天可轉為4，則全選的話，資料庫中存7，和chmod是乙個概念）存放在資料庫欄位中。新增新規則時，sql語句可寫成：select count(1) from ... where 時間重疊 and 可轉天數&new可轉天數》0 and 發放形式&new發放形式》0。如果查詢結果》0，說明有衝突，則不能新增。
最終方案又可以避免刪除操作，也可以直接使用sql語句判斷，而且位運算更快。為了處理方便，建議下拉列表中的選項不包括「全選」，可以新增「全選」按鈕幫助全部選擇，但是無需傳給後台。另因為存在併發查詢，插入，應用分布式鎖來控制併發
工作小記（三）
今天終於是有了突破性的進展。工作中的坑 1.表情序列什麼時候開始，什麼時候終止。2.表情序列的起止時間的判斷 3.表情序列起止時間的訪問 5.老問題，編碼問題 其實很多坑並沒有被 填上 只是我用其他方法繞了過去，但終究只是臨時，是坑的依然是坑，爭取以後有時間了，能把該填的坑都填好。由於是臨時一邊測試...
工作小記 2007 08
朋友看到乙個mysql proxy的專案，簡單看了一下介紹，感覺很不錯，本來一直在打算寫乙個 簡單的，包括這樣幾個功能 1.proxy和db端保持穩定連線數，可以提高資料庫client的併發個數 2.如果db端做cluster,proxy可以對client遮蔽集群的差異 3.其他針對sql語句的功能...
工作小記2
記錄一下最近這段時間的工作狀態，由於工作量不是很大，但是難度還是有的。但是自己呢有點不上心，有時候工作渾渾噩噩，不知道自己在幹嘛，有時候甚至，看著資料就犯睏。也可能與最近工作以外的事情比較煩有關吧。anyway，這段時間的狀態不是很佳，出現了各種不好的狀態，比如厭煩天天一模一樣的工作，討厭上班，想睡...