Oren Eini（又名Ayende Rahien）建議開發者儘量避免數據庫的軟刪除操作，讀者可能因此認爲硬刪除是合理的選擇。作爲對Ayende文章的迴應，Udi Dahan強烈建議完全避免數據刪除。
所謂軟刪除主張在表中增加一個IsDeleted列以保持數據完整。如果某一行設置了IsDeleted標誌列，那麼這一行就被認爲是已刪除的。Ayende覺得這種方法“簡單、容易理解、容易實現、容易溝通”，但“往往是錯的”。問題在於：
刪除一行或一個實體幾乎總不是簡單的事件。它不僅影響模型中的數據，還會影響模型的外觀。所以我們纔要有外鍵去確保不會出現“訂單行”沒有對應的父“訂單”的情況。而這個例子只能算是最簡單的情況。……
當採用軟刪除的時候，不管我們是否情願，都很容易出現數據受損，比如誰都不在意的一個小調整，就可能使“客戶”的“最新訂單”指向一條已經軟刪除的訂單。
如果開發者接到的要求就是從數據庫中刪除數據，要是不建議用軟刪除，那就只能硬刪除了。爲了保證數據一致性，開發者除了刪除直接有關的數據行，還應該級聯地刪除相關數據。可Udi Dahan提醒讀者注意，真實的世界並不是級聯的：
假設市場部決定從商品目錄中刪除一樣商品，那是不是說所有包含了該商品的舊訂單都要一併消失？再級聯下去，這些訂單對應的所有發票是不是也該刪除？這麼一步步刪下去，我們公司的損益報表是不是應該重做了？
沒天理了。
問題似乎出在對“刪除”這詞的解讀上。Dahan給出了這樣的例子：
我說的“刪除”其實是指這產品“停售”了。我們以後不再賣這種產品，清掉庫存以後不再進貨。以後顧客搜索商品或者翻閱目錄的時候不會再看見這種商品，但管倉庫的人暫時還得繼續管理它們。“刪除”是個貪方便的說法。
他接着舉了一些站在用戶角度的正確解讀：
訂單不是被刪除的，是被“取消”的。訂單取消得太晚，還會產生花費。
員工不是被刪除的，是被“解僱”的（也可能是退休了）。還有相應的補償金要處理。
職位不是被刪除的，是被“填補”的（或者招聘申請被撤回）。
在上面這些例子中，我們的着眼點應該放在用戶希望完成的任務上，而非發生在某個
實體身上的技術動作。幾乎在所有的情況下，需要考慮的實體總不止一個。
爲了代替IsDeleted標誌，Dahan建議用一個代表相關數據狀態的字段：有效、停用、取消、棄置等等。用戶可以藉助這樣一個狀態字段回顧過去的數據，作爲決策的依據。
刪除數據除了破壞數據一致性，還有其它負面的後果。Dahan建議把所有數據都留在數據庫裏：“別刪除。就是別
刪除。”
我比較贊同Dahan的思想，採用狀態策略，規避刪除引起的重重負面效果。根據不同業務場景採取不同的狀態標識；比如活動的刪除，應該用取消來標識，活動取消了。但是這個活動還是曾經存在過