聊聊數據庫級聯刪除與僞刪除的設計方案

背景：

這兩天看了重溫了下設計模式和數據結構，又補了下基礎知識，而後就失眠了一整夜，不知爲啥就想到級聯及僞刪數據這個問題。

因爲級聯刪除是幾乎人人都會遇到的問題，但方案卻有限卻不美好，因此歡迎大夥集思文益，如下內容歡迎大夥一塊兒討論。

級聯刪除的方式：

方式1：數據庫設定級聯：

常規MSSQL、MySql、Oracle都對設定了主外鍵關係的表提供級聯刪除。

優勢：數據準確、使用方便，數據庫設計之初就設定好。

缺點：

1：增長對增刪改時外鍵檢測的額外開銷。

2：潛在危險系素大（如：刪除部門或角色，發現一級聯遞歸，整個系統的數據沒了）。

3：不方便觸發其它事件。

4：開發人員可能被屏蔽細節。

整體描述：適合小系統、小局部、無緩存狀態的狀況使用。

整體總結：不多使用。

方式2：觸發器處理。

優勢：DBA喜歡。

缺點：程序員不喜歡，很容易蒙B。

整體描述：適合系統負責人偏DBA愛好的場景，及業務無緩存場景。

整體總結：內部業務系統使用多、外部系統使用少。

方式3：業務代碼控制

優勢：程序員喜歡，自由控制度大。

缺點：程序員喜歡，自由控制度大（隨着業務擴展，須要處處補代碼）。

整體描述：愛自由，愛生活，愛寫代碼。

整體總結：常規方式，在全部系統使用都很普遍。

在方式3的基礎上思考：如何在架構設計統一處理，減小代碼的分佈？

下面聊聊複雜度更高的僞刪除問題：

觸發器刪除及僞刪除

1：觸發器方式

優勢：

1：經過觸發器刪除，並將舊數據移到其它庫或表。

2：數據乾淨，表壓力小。

3：代碼業務邏輯簡單化。

4：DBA喜歡。

5：一手開發人員也喜歡。

缺點：

1：很差控制觸發其它外部業務或事件（如在刪的同時清文件等，但辦法總比困難多）。

2：總體數據庫壓力大（這個還得看業務狀況）。

3：級聯的緩存很差控制（和寫觸發器的同步清楚業務仍是能夠控制）。

4：二接手維護的人員不喜歡。

整體描述：整體缺點不太明顯，後期維護不便。

整體總結：業務系統用的相對較多。

2：僞刪方式

優勢：

1：數據只是標識狀態，數據恢復容易。

2：開發人員喜歡。

缺點：

1：須要在系統各表增長版本號或IsDeleted等標識。

2：業務查詢都須要增長過濾條件。

3：須要級聯更新標識符號。

4：存在髒數據。

5：緩存須要全面控制。

整體描述：優勢不太明顯，缺點是業務代碼分佈複雜了。

整體總結：整體使用並很少。

擴展內容：

1：昨晚無心掃到了吉日一篇文章2010寫的文章，大意是：

花一個星期增長僞刪deletemark字段，改遍了全部業務代碼。（評論主要偏觸發器方案，及致人身攻擊，6年過去了，相信那些人如今應該能淡定看問題了，地址就不貼了。）

2：對於增長字段帶來的問題，有人說用視圖處理。

3：另外看到一個有趣的場景：僞刪後添加相同數據的問題。

增長IsDeleted字段後，把原來的【惟一鍵+IsDeleted】創建聯合主鍵。

刪除後：cyq 0。

新增長：cyq 1。

發現這時候就無法再刪了，再刪就兩個cyq 0 衝突了，你會怎麼解決？

在互聯網上搜僞刪除相關的內容並很少，能夠預見該方案的使用並無普及，緣由可能也在於沒有從架構上能統一處理的方案出現。

思考：如何在架構設計上統一處理，減小業務代碼？

博客園的級聯反應是？

假設博客園要刪除或禁用一個用戶，分析須要處理多少事情？

1：幾乎系統全部表都要關聯處理（文章，評論，點贊，積分，閃存，招聘，博客、知識庫、收藏、新聞等....）

PS：文件、圖片（考慮到文件或圖片外部站大量有引用，不處理。）

2：若緩存須要時時失效（這幾乎是致使整站式緩存瞬間失效，系統要崩了......好在園子目前緩存沒有時效性要求。）

那麼問題來了：

1：園子是全處理了，還只是局部處理呢？

全處理：工做量有點大，代碼分佈有點散，隨着業務增長，還得補充邏輯代碼。

不處理：處處留下的用戶連接致使的404，會不會影響SEO呢？

2：用戶在博問上被採納的內容呢？刪呢？仍是不刪呢？

3：園子目前是採用真刪呢仍是僞刪呢？

 

總結：

1：之前都是本身靜靜思考完，把功能在V5框架裏實現了再分享。

2：如今，分享問題，討論後後，再肯定整體思路。

3：你參與過的項目，如今是用什麼方案呢？覺的方案有改進的空間？