表結構設計討論

--------- 上一個專案啟動前對於表結構設計方面的討論 ---------

1.      多個業務儲存到同一張表

優點：

資料聚集度較高，程式碼量少

缺點：

1)      結構不清晰

2)      由於工作流只能支援單個業務，無法跟工作流結合

 

結論：採用第一種方案。

 

2.      更新修改業務

根據不同的業務型別，分為兩類：

1)      顯式修改，也就是系統需要提供介面修改資訊的，比如單位基本資訊修改、個人基本資訊修改，建議採用統一的通用修改模組實現（該模組目前已實現85%）。可以達到的效果是：把修改資訊作為一筆業務看待，何時修改、何人修改、什麼原因修改、修改了什麼欄位以及原值是什麼，新值是什麼，一清二楚。

2)      隱式修改，即辦理一筆業務，修改了其他相關表資訊的，比如人員增減變動，辦理停保業務，修改了個人基本資訊表中的人員狀態為“停保”。這時候的原始資訊可以透過“歷史資料的保留”討論得出的方案保留。

 

結論：顯式修改，採用通用修改模組修改；隱式修改，視具體的業務具體處理。

 

3.      歷史資料的保留

兩種方案：

1)      在業務表上加入“有效標誌”欄位，0-當前 1-歷史 9-無效

優點：

Ø        java程式處理方便，只對同一張表操作，無需書寫額外的程式碼

Ø        查詢歷史資訊和無效資訊只需要更改標誌標誌即可，透過持久層的封裝統一處理

缺點：

Ø        後臺查詢不方便，加入有效標誌=x,才能區分有效、歷史還是無效記錄

Ø        PL/SQL處理不方便，理由同上

Ø        對於存在業務主鍵（業務唯一性約束）的情況，要保證有效標誌＝0(當前)的情況下，保證唯一，目前Oracle有這樣的機制實現，遷移到資料庫，未確定使用資料庫的機制是否可以實現

Ø        效能損失，a)在同一張表保留歷史和無效資料，日積月累會降低查詢當前記錄的效能，尤其是對於頻繁修改的表，很可能會況會出現歷史資料＋無效資料>當前資料的情況；b)降低使用索引的效能，對於某些存在業務主鍵的表，由於不能對全表資料建立業務主鍵上的唯一索引，只能建立普通索引，必然會導致效能的下降

Ø        資料量特別大的表情況，出於效能上的考慮，不太合適

2)      建立歷史表，表結構跟原表一樣，但需要加入

優點：

Ø        歷史、無效資料和當前資料隔離，不存在效能降低的問題

Ø        可以在業務主鍵上建立唯一索引，不存在“有效標誌”出現的問題

缺點：

Ø        對每張需要保留歷史記錄的表都需要建立歷史表

Ø        java程式上的處理要對多張表操作，存在不夠方便（是否考慮使用通用的一種處理方式？）

 

結論：採用第二種方案，對每張需要保留歷史記錄的表都建立歷史表，命名方法為原表名＋_BAK，加入xgr-修改人，xgsj-修改時間，scr-刪除人，scsj-刪除時間四個欄位；持久層在修改和刪除表資料的時候保留歷史、無效資訊，並且提供查詢歷史、無效資料的介面。

 

4.      支付賬目的設計

有兩種設計方法：

1)      主從表：從表儲存明細項金額，主表儲存彙總金額和狀態資訊

優點：

Ø        靈活，明細項有增加減少變化時，相應的從表增加減少記錄，對錶結構沒有影響

缺點：

Ø        資料量較大，比如在沖銷的時候，明細資訊也要同時沖銷，可能會存在效能問題

2)      單表：

優點：

Ø        資料量較第一種方法要少

缺點：

Ø        不靈活，明細項增加減少時需要增加減少欄位

 

結論：採用第一種方案。