背景：
這兩天看了重溫了下設計模式和數據結構，又補了下基礎知識，然后就失眠了一整夜，不知為啥就想到級聯及偽刪數據這個問題。
由於級聯刪除是幾乎人人都會遇到的問題，但方案卻有限卻不美好，所以歡迎大伙集思文益，以下內容歡迎大伙一起討論。
級聯刪除的方式：
方式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：你參與過的項目，現在是用什么方案呢？覺的方案有改進的空間？