最近幾天有點忙，所以我們今天來一篇短的，簡單地介紹一下數據庫設計中的一種模式——Soft Delete。

　　可以說，該模式毀譽參半，甚至有非常多的人認為該模式是一個Anti-Pattern。因此在本篇文章中，我們不僅僅會對該模式進行介紹，同時也會列出該模式可能導致的一系列問題，以幫助大家正確地決定是否使用該模式。

Soft Delete簡介

　　首先先來想一個需求，那就是對用戶操作的回滾支持。例如我現在正在用Word編寫這篇文章。當我執行了一個錯誤操作的時候，我僅僅需要鍵入Ctrl + Z就可以進行回滾。而在有些Web應用中，我們同樣需要這種功能。

　　例如Rally是一個Web應用，以用來在軟件開發過程中對進度和任務進行管理。在任務管理功能中，每次對任務的創建，修改以及刪除都會被記錄在系統中。

　　現在問題來了，如果需要支持回滾，那么系統該如何記錄一條已經被用戶刪除了的任務呢？最直觀的想法就是在數據庫中添加一列deleted來記錄該任務是否已經被刪除：

 1 @Entity
 2 class Task extends … {
 3     private boolean deleted;
 4     ……
 5     private boolean isDeleted() {
 6         return deleted;
 7     }
 8 
 9     private void setDeleted(boolean deleted) {
10         this.deleted = deleted;
11     }
12 }

　　如果一個任務被刪除了，那么它的deleted將為true。也就是說，在用戶刪除一個任務的時候，系統實際上并沒有將該任務徹底地從數據庫中刪除，而僅僅是通過deleted來標示其已經被刪除了。而在恢復該任務的時候，只需要將deleted設置為false即可。

　　OK，這就是有關Soft Delete模式的介紹。是不是很簡單？但也正是因為它非常簡單，進而導致了對它的濫用，從而使它成為了一個很多人眼中的Anti-Pattern。這種事情在IT技術中發生的還真是不少。最簡單的就是Java的Checked Exception。的確它是一個好的功能，讓使用Java編程變得更加嚴謹。但是過分的濫用導致很多類庫都將用戶完全無法處理的異常暴露在了類庫接口中，反而使很多軟件開發人員養成了直接忽略所有異常的壞習慣：

1 try {
2     obj.someFunction();
3 } catch (Throwable e) {
4 }

　　相信讀者已經看出了這么做的危害：catch甚至將表示系統錯誤的Error類型實例都抓住了。但這里不能忽略的一個事實是，當軟件開發人員對某些行為無能為力，那么他極有可能忽略某些編碼準則，而首先選擇使用一種能讓系統在正確運行的情況下工作起來的方法。例如對于上面的函數調用obj.someFunction()，如果其拋出的異常和類庫內部運行邏輯相關，而且每次都可能導致這種問題，那么軟件開發人員就極有可能使用上面的代碼忽略掉該異常。這種問題甚至在一些廣為使用的類庫中存在著。例如OData4j曾經把取得OData元數據時產生的所有異常都當作是目標服務沒有暴露元數據的情況來處理。

　　OK，說得有點遠了?？偨Y起來就是，一旦一個技術過于簡單而且能夠處理某個情況，那么軟件開發人員將不會仔細研究使用該技術所需要的語境，從而導致濫用。和Checked Exception一樣，Soft Delete也是這樣的一個例子。

Soft Delete的問題

　　那么該數據庫模式有什么問題呢？簡單地說，那就是太容易出錯，而且是隱蔽的錯誤。試想一下，如果用戶需要列出所有的任務，那么在SQL語句中就需要使用WHERE deleted = ‘N’這樣的條件。而且該條件幾乎在所有處理任務的SQL語句中都要出現。一旦在一個SQL語句中忘記了該條件，那么這極有可能是一個Bug，而且這種Bug有時候還非常隱蔽。例如如果在一個COUNT語句中忘記標示了該條件，而且系統中任務很多，但是被刪除的任務很少，那么該Bug可能存在幾年都不會被發現。

　　同時如果一旦決定需要在系統中大量地使用Soft Delete，那么SQL將變得非常混雜。在統計功能中，我們可能需要篩選出所有包含任務的用例的個數，甚至是包含這些用例的項目的個數，那么我們就需要在SQL中同時標明多個WHERE deleted = ‘N’的條件：

1 SELECT COUNT(*)
2 FROM project, story, task
3 WHERE … project.deleted = ‘N’ AND story.deleted = ‘N’ AND task.deleted = ‘N’

　　那么在調試這些語句的時候，或者查看這些語句的執行計劃以進行性能調優的時候，軟件開發人員都會發現由于這些條件的引入導致SQL的執行變得非常復雜。

　　還有一個問題就是，如果一個系統常常執行對記錄的軟刪除，那么數據庫中所記錄的數據將比實際所需要記錄的數據多得多。這種垃圾數據可能會導致數據庫的索引變得很大，甚至可能會由此而嚴重影響數據庫的性能。

　　另一個問題則和級聯有關。數據庫提供了級聯操作，在刪除一個數據記錄的時候，數據庫會根據該數據與其它記錄之間的關聯關系來自動完成對其它關聯記錄的操作。這也是數據庫保持其數據完整性的一種方法。但是一旦用戶使用了Soft Delete，那么在對其進行軟刪除的時候就不會將其從數據庫中移除，那么與其關聯的那些記錄也便不會被數據庫移除。也就是說，軟件開發人員需要自行完成數據完整性的管理。除此之外，軟件開發人員還需要在數據訪問層（DAL，Data Access Layer）中完成事務的組織，并且一旦數據庫表的定義發生了變化，這些事務組織的邏輯也可能需要進行更改。

Soft Delete的實現

　　也正是由于Soft Delete擁有這么多的問題，因此軟件開發人員們提出了很多Soft Delete的變通實現方法，大大地減少了開發和維護Soft Delete模式數據的成本。

　　一種方法就是利用數據庫所提供的View功能。在該方法中，我們需要在數據庫中創建一個View，以顯示表中deleted值為’N’的各行數據。而在對數據進行操作的各SQL語句中，我們只需要直接操作該View，從而避免了每次都需要在SQL語句中標明WHERE deleted = ‘N’這種條件。

　　而另一種方法則是將這些數據分散到兩個不同的表中。這兩個表中的一個表記錄deleted值為’N’的各行數據，而另一個表則記錄已經被軟刪除的deleted值為’Y’的各行數據。而且在具有兩個表的情況下，系統甚至可以很較為容易地實現垃圾箱的功能。

　　而在某些情況下，我們也可以在數據庫設計中借鑒Soft Delete的思路。Soft Delete需要用戶自行管理數據庫中數據的關聯關系。這是一份額外的工作，但也帶來了更多的靈活性。

　　Rally中的任務刪除操作的回滾自然不必多說，垃圾箱功能的添加也將變為非常容易的事。而對于某些自定義的刪除邏輯，Soft Delete所帶來的靈活性將更為突出。例如在Rally中，如果我們需要實現“刪除用戶用例時如果用戶用例中包含任務，那么這些任務將挪至父用例中”這樣一個需求，那么我們就可以在Soft Delete的自定義刪除邏輯中完成該功能。

　　好了，今天就到這里。