在進行公司專屬應用程式系統開發時,在多使用者模式下,對各種業務資料如何避免並行作業引起資料異常是設計中非常重要的考量點。下面總結已遇到的一些情境及對應解決辦法,並不完整全面。
情境:同時編輯同一業務資料
問題描述:
甲開啟某業務資料編輯頁首,乙也開啟此編輯頁首,甲乙先後執行保持操作。
如儲存時不做控制,後儲存者的資料覆蓋先儲存者的資料。
Ø 處理辦法A:
開啟編輯頁首後,儲存業務資料時間戳記,儲存時檢查是否一致,如不一致則提示,由使用者選擇是否儲存。
優點:給以使用者選擇權。缺點:使用者有時無法判斷,可能造成資料異常。
注意事項:
當編輯頁麵包含子表的編輯和儲存功能時,方案A很可能引起資料異常。除非子表的儲存方法是先刪除再新增。
Ø 處理辦法B:
開啟編輯頁首後,儲存業務資料時間戳記,儲存時檢查是否一致,如不一致則提示不允許儲存。
Ø 處理辦法C:
不做控制,僅記錄儲存時間和儲存人員
情境:在業務過程中改變業務資料的狀態同時,業務資料發生改變
問題描述:
甲開啟某業務資料進行審核,在其點擊審核前,乙開啟業務資料修改並先保持;
甲開啟某業務資料進行審核,在其點擊審核前,乙開啟業務資料修改,甲點擊審核後乙點擊儲存;
(業務資料的“審核”、“作廢”或其他某特殊業務狀態欄位的改變均適用此情境)
Ø 處理辦法A:
開啟查看頁面時,記錄時間戳記,審核時比較時間戳記。儲存業務資料時,同樣比較時間戳記,不同時不允許儲存。
Ø 處理辦法B:
將審核動作分為“提交審核”和“確認審核”兩個步驟,提交審核後,不允許修改。
漏洞:甲提交審核頁面動作發生前,乙開啟修改頁面,甲再確認審核,之後乙儲存修改,如此則甲的審核操作從業務和資料狀態上都有可能不正確。
Ø 處理辦法C:
開啟編輯頁面時,記錄業務狀態值,儲存時比較此值,如不同則不允許儲存。
情境:編輯的同時業務資料被刪除
問題描述:
甲開啟業務資料進行編輯,乙將此資料刪除,甲再進行儲存動作
Ø 處理辦法:
儲存時,先檢查該業務資料是否存在。通常是按ID取業務資料,判斷是否存在,如存在則進行資料的修改和儲存。
在不存在時,反饋客戶相關資訊,不允許儲存。
情境:業務關聯資料被刪除
問題描述:
甲開啟業務資料,此時業務資料中某一關聯資料被刪除,根據關聯資訊取不到關聯資料的值。
甲編輯業務資料,選取某一關聯資料,乙刪除此關聯資料,甲執行保持操作。
Ø 解決辦法A:
通過資料庫設定外鍵欄位,在資料庫層面避免資料異常。在程式中通過捕獲異常來給以客戶適當提示。
缺陷:依賴資料庫,某種情況下會造成效能問題(備忘1);
備忘1:假設A表被多張表設為外部索引鍵關聯,且關聯表資料量大,則更新A表欄位時有可能造成同時檢查更新其他關聯表,效能下降明顯。
Ø 解決辦法B:
對被關聯的資料,從業務上不允許被刪除
缺陷:代碼量大,容易遺漏;
辦法A和B可相互補充
情境:業務關聯資料被修改
問題描述:
業務資料中,關聯的資料被改,如合約表中的客戶姓名本來為A,合約中儲存客戶表ID。之後客戶表中A的名字被改為B。此時開啟合約頁面,客戶名字變為B。
此情境的正確解決辦法嚴重依賴於具體業務情境。如上例,假設修改客戶名字的唯一途徑就是修改客戶表,可能上述現象是正常業務表現,假設合約中客戶姓名不能隨意被改動,上述現象就是資料異常。
Ø 解決辦法A:
在修改客戶姓名時,檢查是否有關聯合約,如有,則不允許修改,或設計另一頁面(業務通道)來修改客戶姓名。
缺陷:僅在關聯及其強的情況下適用,代碼量大,商務邏輯複雜。
Ø 解決辦法B:
在合約中記錄客戶的姓名、連絡方式等關鍵資訊,實質上是通過冗餘來避免關鍵資訊被修改。同時提供同步客戶資訊表中相關欄位的選擇。
缺陷:僅在關聯及其強的情況下適用,代碼量大,商務邏輯複雜。
Ø 解決辦法C:
不予處理,僅在實施時提示客戶。