在數(shù)據(jù)庫(kù)設(shè)計(jì)中，當(dāng)刪除一條記錄的時(shí)候，是加一個(gè)標(biāo)記位還是直接刪除這一行？

物理刪除：真刪除，數(shù)據(jù)消失。
邏輯刪除：假刪除，數(shù)據(jù)存在，只是用一個(gè)字段來(lái)標(biāo)記該條數(shù)據(jù)“已刪除”。

---

參考了一些網(wǎng)絡(luò)上的討論如下：

關(guān)于soft delete的好處，justjavac的介紹很棒。

不過(guò)是否應(yīng)該使用soft delete，還是需要慎重考慮。

在關(guān)系型數(shù)據(jù)庫(kù)中，軟刪除(soft delete)主要影響的是write的效率，而不是read，所以在這種情況下，考慮采用soft delete的可行性的時(shí)候，也要考慮你的table/database面對(duì)的是否是write intensive的需求。另外，采用soft delete，一般是為了可能的恢復(fù)，為了audit，為了保存歷史數(shù)據(jù)等等目的。那么為了某個(gè)或者某些數(shù)據(jù)，是否soft delete真的是最好的處理方式呢？比如為了log的auditing，而對(duì)log采用soft delete，或許就有一些小題大做了。

而對(duì)于NoSQL數(shù)據(jù)庫(kù)，軟刪除通常來(lái)講是很容易接收的。尤其是Key-Value的NoSQL數(shù)據(jù)庫(kù)，比如Amazon的Dynamo DB和Riak等等，實(shí)現(xiàn)原理是hash table，所以就算有大量的soft delete數(shù)據(jù)，也不會(huì)對(duì)性能造成巨大的影響。而對(duì)于其他類型的NoSQL數(shù)據(jù)庫(kù)，Document-based(比如CouchDB)或者Column-based(比如hbase)等等，data integrity重要性也是遠(yuǎn)遠(yuǎn)超過(guò)采用soft delete帶來(lái)的性能下降的。

---

小數(shù)據(jù)無(wú)所謂，看需求了
數(shù)據(jù)量大，最好另建一表保存刪除數(shù)據(jù)
刪除的很少用

---

根據(jù)需求而定，以后基本不用的數(shù)據(jù)完全可以刪除（可以采取緩沖處理，先標(biāo)記，后在系統(tǒng)不忙時(shí)刪除）節(jié)省空間，減少無(wú)用檢索；另一種情況，數(shù)據(jù)以后可能被重復(fù)利用，則打上標(biāo)記，空閑時(shí)移到歷史庫(kù)。

關(guān)系數(shù)據(jù)庫(kù)用來(lái)記錄當(dāng)前的客觀事實(shí)，增、刪、改，對(duì)應(yīng)事實(shí)的改變。
有一種類型的表稱為“history table”（或"audit table"），他們是專門用來(lái)記錄歷史數(shù)據(jù)的。通過(guò)trigger或存儲(chǔ)過(guò)程實(shí)現(xiàn)。他們的功能跟其他表不同，他們記錄的是對(duì)數(shù)據(jù)庫(kù)的操作，不是業(yè)務(wù)范圍的事實(shí)。history table通常數(shù)據(jù)量會(huì)隨時(shí)間越來(lái)越大，它們沒(méi)有刪、改，只有增、查(少量的查)，而current table中的數(shù)據(jù)量相對(duì)較小，正好滿足業(yè)務(wù)需要（增、刪、改、查）。

---

打標(biāo)記好，萬(wàn)一是某人發(fā)布了敏感言論然后刪除，那么警察叔叔查水表的難度肯定比用delete刪除的難度小的多。

---

數(shù)據(jù)庫(kù)設(shè)計(jì)原則–不要?jiǎng)h除數(shù)據(jù)

摘自Segment的問(wèn)題回復(fù)，個(gè)人認(rèn)為是對(duì)數(shù)據(jù)庫(kù)中刪除操作最好的詮釋，大部分情況下我們是濫用刪除或刪除標(biāo)記，真實(shí)情況中大部分情況我們只需修改記錄的狀態(tài)即可。因此在做數(shù)據(jù)庫(kù)設(shè)計(jì)中，我們決定使用刪除或刪除標(biāo)記的時(shí)候，我們需要再思考一次：在業(yè)務(wù)上，這真的是刪除操作嗎？

Udi Dahan 強(qiáng)烈建議完全避免數(shù)據(jù)刪除。

所謂軟刪除主張?jiān)诒碇性黾右粋€(gè) IsDeleted 列以保持?jǐn)?shù)據(jù)完整。如果某一行設(shè)置了IsDeleted標(biāo)志列，那么這一行就被認(rèn)為是已刪除的。Ayende 覺(jué)得這種方法“簡(jiǎn)單、容易理解、容易實(shí)現(xiàn)、容易溝通”，但“往往是錯(cuò)的”。問(wèn)題在于：

刪除一行或一個(gè)實(shí)體幾乎總不是簡(jiǎn)單的事件。它不僅影響模型中的數(shù)據(jù)，還會(huì)影響模型的外觀。所以我們才要有外鍵去確保不會(huì)出現(xiàn)“訂單行”沒(méi)有對(duì)應(yīng)的父“訂單”的情況。而這個(gè)例子只能算是最簡(jiǎn)單的情況。……

當(dāng)采用軟刪除的時(shí)候，不管我們是否情愿，都很容易出現(xiàn)數(shù)據(jù)受損，比如誰(shuí)都不在意的一個(gè)小調(diào)整，就可能使“客戶”的“最新訂單”指向一條已經(jīng)軟刪除的訂單。

如果開發(fā)者接到的要求就是從數(shù)據(jù)庫(kù)中刪除數(shù)據(jù)，要是不建議用軟刪除，那就只能硬刪除了。為了保證數(shù)據(jù)一致性，開發(fā)者除了刪除直接有關(guān)的數(shù)據(jù)行，還應(yīng)該級(jí)聯(lián)地刪除相關(guān)數(shù)據(jù)。可Udi
Dahan提醒讀者注意，真實(shí)的世界并不是級(jí)聯(lián)的：

假設(shè)市場(chǎng)部決定從商品目錄中刪除一樣商品，那是不是說(shuō)所有包含了該商品的舊訂單都要一并消失？再級(jí)聯(lián)下去，這些訂單對(duì)應(yīng)的所有發(fā)票是不是也該刪除？這么一步步刪下去，我們公司的損益報(bào)表是不是應(yīng)該重做了？

沒(méi)天理了。

問(wèn)題似乎出在對(duì)“刪除”這詞的解讀上。Dahan 給出了這樣的例子：

我說(shuō)的“刪除”其實(shí)是指這產(chǎn)品“停售”了。我們以后不再賣這種產(chǎn)品，清掉庫(kù)存以后不再進(jìn)貨。以后顧客搜索商品或者翻閱目錄的時(shí)候不會(huì)再看見這種商品，但管倉(cāng)庫(kù)的人暫時(shí)還得繼續(xù)管理它們。“刪除”是個(gè)貪方便的說(shuō)法。

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

訂單不是被刪除的，是被“取消”的。訂單取消得太晚，還會(huì)產(chǎn)生花費(fèi)。
員工不是被刪除的，是被“解雇”的（也可能是退休了）。還有相應(yīng)的補(bǔ)償金要處理。
職位不是被刪除的，是被“填補(bǔ)”的（或者招聘申請(qǐng)被撤回）。

在上面這些例子中，我們的著眼點(diǎn)應(yīng)該放在用戶希望完成的任務(wù)上，而非發(fā)生在某個(gè)實(shí)體身上的技術(shù)動(dòng)作。幾乎在所有的情況下，需要考慮的實(shí)體總不止一個(gè)。

為了代替 IsDeleted 標(biāo)志，Dahan 建議用一個(gè)代表相關(guān)數(shù)據(jù)狀態(tài)的字段：有效、停用、取消、棄置等等。用戶可以借助這樣一個(gè)狀態(tài)字段回顧過(guò)去的數(shù)據(jù)，作為決策的依據(jù)。

刪除數(shù)據(jù)除了破壞數(shù)據(jù)一致性，還有其它負(fù)面的后果。Dahan建議把所有數(shù)據(jù)都留在數(shù)據(jù)庫(kù)里：“別刪除。就是別刪除。”

—— 《NoSQL數(shù)據(jù)庫(kù)筆談》

---

總結(jié)

以上是生活随笔為你收集整理的数据库设计原则：应该使用软删除吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。