別刪除資料

oren eini（又名ayende rahien）建議開發者盡量避免資料庫的軟刪除操作，讀者可能因此認為硬刪除是合理的選擇。作為對ayende文章的回應，udi dahan強烈建議完全避免資料刪除。

所謂軟刪除主張在表中增加乙個isdeleted列以保持資料完整。如果某一行設定了isdeleted標誌列，那麼這一行就被認為是已刪除的。ayende覺得這種方法「簡單、容易理解、容易實現、容易溝通」，但「往往是錯的」。問題在於：

刪除一行或乙個實體幾乎總不是簡單的事件。它不僅影響模型中的資料，還會影響模型的外觀。所以我們才要有外來鍵去確保不會出現「訂單行」沒有對應的父「訂單」的情況。而這個例子只能算是最簡單的情況。…… 當採用軟刪除的時候，不管我們是否情願，都很容易出現資料受損，比如誰都不在意的乙個小調整，

就可能使「客戶」的「最新訂單」指向一條已經軟刪除的訂單。

如果開發者接到的要求就是從資料庫中刪除資料，要是不建議用軟刪除，那就只能硬刪除了。為了保證資料一致性，開發者除了刪除直接有關的資料行，還應該級聯地刪除相關資料。可udi dahan提醒讀者注意，真實的世界並不是級聯的：

假設市場部決定從商品目錄中刪除一樣商品，那是不是說所有包含了該商品的舊訂單都要一併消失？再級聯下去，這些訂單對應的所有發票是不是也該刪除？這麼一步步刪下去，我們公司的損益報表是不是應該重做了？

沒天理了。

問題似乎出在對「刪除」這詞的解讀上。dahan給出了這樣的例子：

我說的「刪除」其實是指這產品「停售」了。我們以後不再賣這種產品，清掉庫存以後不再進貨。


他接著舉了一些站在使用者角度的正確解讀：

訂單不是被刪除的，是被「取消」的。訂單取消得太晚，還會產生花費。員工不是被刪除的，是被「解雇」的（也可能是退休了）。還有相應的補償金要處理。職位不是被刪除的，是被「填補」的（或者招聘申請被撤回）。在上面這些例子中，我們的著眼點應該放在使用者希望完成的任務上，而非發生在某個實體身上的技術動作。

幾乎在所有的情況下，需要考慮的實體總不止乙個。