B端產(chǎn)品的設計，幾乎都是在圍繞新增、刪除、修改、查詢、顯示、計算、傳輸、業(yè)務流做工作，而增刪改查是原型設計中基礎的基礎。“刪除”數(shù)據(jù)的方式有刪除、禁用、失效，那么，選擇的邏輯是什么呢？本文作者分享了自己的看法，一起來看一下吧。

B端產(chǎn)品的設計，幾乎都是在圍繞新增、刪除、修改、查詢、顯示、計算、傳輸、業(yè)務流做工作，而增刪改查是原型設計中基礎的基礎。

今天的文章不長，圍繞最近反復被討論的一個點分享一下我個人的看法：“刪除”數(shù)據(jù)的方式有刪除、禁用、失效，選擇的邏輯是什么？

01 數(shù)據(jù)刪除的邏輯

兩年前的時候我寫過一篇文章《增刪改查顯算傳，七字箴言搭建ToB系統(tǒng)底層框架》，至今看來還算是抽象、概括性比較高的，為便于讀者理解，這里就直接引用了。

數(shù)據(jù)有新增的路徑，就會存在刪除的需求。通常說的刪除，包含兩種：

1. 物理刪除：真實刪除，從數(shù)據(jù)庫層面刪除了數(shù)據(jù)，查詢找不到該條數(shù)據(jù)，數(shù)據(jù)不可恢復。一般對于重要的基礎數(shù)據(jù)，不建議設置刪除功能，設計中要避免不可逆的操作；
2. 邏輯刪除：假刪除，只是從頁面對數(shù)據(jù)進行了刪除，數(shù)據(jù)庫將數(shù)據(jù)的狀態(tài)改寫為“已刪除”，可通過刪除后撤回或者數(shù)據(jù)庫備份恢復，產(chǎn)品設計中比較常用。

數(shù)據(jù)的前后業(yè)務關聯(lián)太強，不適合設計刪除功能，那應該如何對數(shù)據(jù)進行合理的處理呢？個人理解的刪除需求的存在，可能存在以下幾種情況：

• 過期無用信息：可以設計數(shù)據(jù)庫定時任務，根據(jù)實際的業(yè)務情況和指定條件，定期清理垃圾數(shù)據(jù)，適用于數(shù)據(jù)量較大的情況；
• 信息錄入錯誤：邏輯刪除或者使用編輯功能修改數(shù)據(jù)；
• 數(shù)據(jù)狀態(tài)改變，或需要中止業(yè)務：使用字典狀態(tài)來限制。

文章中對刪除邏輯和適用范圍的理解依然有效，但是不足之處在于具體使用場景的描述不夠詳細。接下來我們就聊一聊刪除、禁用、失效的適用場景和區(qū)別在哪里。

02 刪除、禁用、失效的適用場景

1. 刪除的適用場景

根據(jù)尼爾森十大可用性設計原則，為了避免用戶的誤用和誤擊，系統(tǒng)應提供撤銷和重做功能。日常高頻新增的數(shù)據(jù)，人工輸入就有可能產(chǎn)生誤差。從體驗的角度來看，系統(tǒng)要允許刪除數(shù)據(jù)。

刪除分為即時刪除（提交信息之后的toast提供撤回和重做的選項）和事后刪除（在列表或詳情中提供刪除功能）。

即時刪除通常用于輕量化信息的提交，因為輕量化的信息內(nèi)容簡單，提交后腦海中對信息還有整體的印象，而且和業(yè)務的耦合度低，從技術層面來說做數(shù)據(jù)的回滾也不容易出錯，例如滴答清單筆記的立即撤回。

這里的撤回即軟刪除，并沒有從數(shù)據(jù)庫層面刪除掉數(shù)據(jù)，而是將數(shù)據(jù)從已提交可撤回的狀態(tài)變?yōu)榱丝删庉嫽蛘咭烟峤坏臓顟B(tài)。

1）輕量化信息的刪除——立即撤回

在后臺系統(tǒng)的設計中，事后刪除一般和列表同步出現(xiàn)。

這里有個點可以發(fā)散一下：為什么刪除按鈕不在詳情頁而是列表頁呢？至少有一點，詳情頁的刪除不滿足批量刪除的需求。

2）某電商后臺的數(shù)據(jù)列表——刪除

小結(jié)一下，除了高頻新增這一個場景，使用刪除還需要滿足一個場景：非核心、低耦合的數(shù)據(jù)，這和“禁用”以及“失效”是對立的。

Tips:當刪除數(shù)據(jù)是一項危險的操作時，也需要在確認過程中警示，例如二次彈窗確認（刪除后不可恢復提示、刪除影響提示）、高亮文字等。

2. 禁用的適用場景

數(shù)據(jù)變得無用，不能被其他業(yè)務引用，又不能刪除，怎么辦呢？可以使用“禁用、停用、作廢”功能來控制數(shù)據(jù)的有效性和可見范圍。

例如我司為以銷定采（根據(jù)客戶的訂單進行采購，不提前采購庫存）的業(yè)務模式，為了保證發(fā)貨的及時性，在生成訂單之后定時器會自動觸發(fā)生成采購單。

但是難免存在客戶臨時取消、修改訂單的情況，如果在數(shù)據(jù)庫層面做刪除操作，這類訂單將不可追溯，會導致多采。

所以我們最終采用了作廢這種形式，通過作廢標記的訂單，指定人員可見，在特殊的業(yè)務環(huán)節(jié)做核銷即可。筆者對財務系統(tǒng)接觸不深，這和發(fā)票的紅沖應該是差不多的意思。

再例如Oracle中有一個設計是可以禁用物料分類，這也是出于業(yè)務的耦合度較高，信息需要留存，但是不適合再被后期的其他業(yè)務引用產(chǎn)生新的數(shù)據(jù)有關。

小結(jié)一下，業(yè)務的耦合度高，數(shù)據(jù)有變更會對其他業(yè)務產(chǎn)生影響需要保留的情況下，就可以采用“禁用、停用、作廢”這種形式來做數(shù)據(jù)的刪除。

3. 失效的適用場景

失效和禁用類似，區(qū)別在于數(shù)據(jù)的失效是否有明確的截止時間。

例如權限控制中會通過有效期控制員工的賬號，因為員工的離職是有明確時間節(jié)點的，而且是在將來發(fā)生，在發(fā)生之前賬號還要保持可使用的狀態(tài)。

使用刪除和禁用都不合適，一方面是要求當場操作，時效的要求較高（禁用），如果遺忘可能會產(chǎn)生損失；另一方面是會影響到其他相關數(shù)據(jù)，例如員工尚未完結(jié)的薪酬（刪除）。

再例如 Oracle 中會判斷物料的有效期來決定是否可以被其他業(yè)務引用，對應的場景就是 B 端商貿(mào)業(yè)務中，商品的調(diào)價或者產(chǎn)品下線均是有計劃出現(xiàn)。通過截止時間使物料失效，方便采購、倉儲人員提前做好物料管理計劃。

價目表通過有效期來控制數(shù)據(jù)的可見性也是一樣的道理。

小結(jié)一下，在禁用的基礎上，如果數(shù)據(jù)有明確的截止時間，可通過調(diào)整失效時間來提前做數(shù)據(jù)規(guī)劃或“刪除”。

03 組織架構的“禁用”是要禁用人員的賬號嗎？

這個問題發(fā)生的背景是有學員提問，組織架構中有“禁用”的功能，這里的禁用是為了讓組織架構下的員工賬號失效，不能訪問系統(tǒng)嗎？

其實這個問題暴露了兩個沒有被理解的業(yè)務場景和一個產(chǎn)品設計原則：

• 組織架構是什么
• 組織架構的變更意味著什么
• 低耦合，高內(nèi)聚

看馮侖的《野蠻生成》（點擊查看讀書筆記）對于企業(yè)的組織架構設定有所感觸，當時在讀書筆記中寫道：之前一直想輸出一篇組織架構的變更對企業(yè)的影響，現(xiàn)在發(fā)現(xiàn)自己的理解思路錯了。組織是為目標服務的，人群行為的管理也是為了達成目標。所以，往上一層思考，應該研究企業(yè)目標的變化對企業(yè)的組織架構、人群行為的影響。

Oracle（僅針對筆者接受的Oracle培訓課，Oracle完整產(chǎn)品過于龐大，筆者還沒有機會了解其全貌）將OMS產(chǎn)品的組織劃分為四大類：庫存組織、HR組織、業(yè)務實體、財務套賬，這些對應的就是收入和成本數(shù)據(jù)。

在筆者接觸的B端產(chǎn)品設計中，組織架構的劃分就是按照成本組織和收入組織來規(guī)劃的，嚴格匹配企業(yè)的戰(zhàn)略目標，當目標發(fā)生變更，組織中資源的分配就會隨之調(diào)整，所以產(chǎn)生了組織架構的新增和“刪除”。（問題中學員提出的“禁用組織架構”其實也有誤差，應該是使組織架構失效，因為組織架構的變更通常是有規(guī)劃進行的，不是突然發(fā)生的事件。）

在某個組織被變更后，組織內(nèi)產(chǎn)生的成本和收入依然會進入財務體系核算，不宜刪除，人員作為成本的一部分，數(shù)據(jù)自然也要保留在系統(tǒng)中。

所以組織內(nèi)的人員會遷移到其他部門或者離職，因此需要對組織下個人賬號做所屬組織修改或者賬號失效處理。

回到產(chǎn)品設計本身，我們有一個原則是一次只做一件事情，產(chǎn)品架構的設計要符合低耦合的原則。

組織的失效是對組織的相關數(shù)據(jù)做了凍結(jié)處理，凍結(jié)的前提條件是組織內(nèi)正在有效的數(shù)據(jù)、賬號需要遷移到其他組織下或者同時也使之失效。這個“前提”是另外要單獨做的事情，禁用組織和禁用人員賬號，是兩碼事。

嘮嘮叨叨寫了這么多，最后來個總結(jié)：

1. 高頻新增和非核心、低耦合的數(shù)據(jù)，使用刪除功能；
2. 業(yè)務的耦合度高（數(shù)據(jù)有變更也會對其他業(yè)務產(chǎn)生影響需要保留的情況下）采用“禁用、停用、作廢”來做數(shù)據(jù)的刪除；
3. 在禁用的基礎上，如果數(shù)據(jù)有明確的截止時間，可通過調(diào)整失效時間來提前做數(shù)據(jù)規(guī)劃或“刪除”。