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

今天的文章不長，圍繞最近反複被讨論的一個點分享一下我個人的看法：“删除”數據的方式有删除、禁用、失效，選擇的邏輯是什麼？

01 數據删除的邏輯

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

數據有新增的路徑，就會存在删除的需求。通常說的删除，包含兩種：

1. 物理删除：真實删除，從數據庫層面删除了數據，查詢找不到該條數據，數據不可恢複。一般對于重要的基礎數據，不建議設置删除功能，設計中要避免不可逆的操作；
2. 邏輯删除：假删除，隻是從頁面對數據進行了删除，數據庫将數據的狀态改寫為“已删除”，可通過删除後撤回或者數據庫備份恢複，産品設計中比較常用。

數據的前後業務關聯太強，不适合設計删除功能，那應該如何對數據進行合理的處理呢？個人理解的删除需求的存在，可能存在以下幾種情況：

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

文章中對删除邏輯和适用範圍的理解依然有效，但是不足之處在于具體使用場景的描述不夠詳細。接下來我們就聊一聊删除、禁用、失效的适用場景和區别在哪裡。

02 删除、禁用、失效的适用場景

1. 删除的适用場景

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

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

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

這裡的撤回即軟删除，并沒有從數據庫層面删除掉數據，而是将數據從已提交可撤回的狀态變為了可編輯或者已提交的狀态。

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

在後台系統的設計中，事後删除一般和列表同步出現。

這裡有個點可以發散一下：為什麼删除按鈕不在詳情頁而是列表頁呢？至少有一點，詳情頁的删除不滿足批量删除的需求。

2）某電商後台的數據列表——删除

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

Tips:當删除數據是一項危險的操作時，也需要在确認過程中警示，例如二次彈窗确認（删除後不可恢複提示、删除影響提示）、高亮文字等。

2. 禁用的适用場景

數據變得無用，不能被其他業務引用，又不能删除，怎麼辦呢？可以使用“禁用、停用、作廢”功能來控制數據的有效性和可見範圍。

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

但是難免存在客戶臨時取消、修改訂單的情況，如果在數據庫層面做删除操作，這類訂單将不可追溯，會導緻多采。

所以我們最終采用了作廢這種形式，通過作廢标記的訂單，指定人員可見，在特殊的業務環節做核銷即可。筆者對财務系統接觸不深，這和發票的紅沖應該是差不多的意思。

再例如Oracle中有一個設計是可以禁用物料分類，這也是出于業務的耦合度較高，信息需要留存，但是不适合再被後期的其他業務引用産生新的數據有關。

小結一下，業務的耦合度高，數據有變更會對其他業務産生影響需要保留的情況下，就可以采用“禁用、停用、作廢”這種形式來做數據的删除。

3. 失效的适用場景

失效和禁用類似，區别在于數據的失效是否有明确的截止時間。

例如權限控制中會通過有效期控制員工的賬号，因為員工的離職是有明确時間節點的，而且是在将來發生，在發生之前賬号還要保持可使用的狀态。

使用删除和禁用都不合适，一方面是要求當場操作，時效的要求較高（禁用），如果遺忘可能會産生損失；另一方面是會影響到其他相關數據，例如員工尚未完結的薪酬（删除）。

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

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

小結一下，在禁用的基礎上，如果數據有明确的截止時間，可通過調整失效時間來提前做數據規劃或“删除”。

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

這個問題發生的背景是有學員提問，組織架構中有“禁用”的功能，這裡的禁用是為了讓組織架構下的員工賬号失效，不能訪問系統嗎？

其實這個問題暴露了兩個沒有被理解的業務場景和一個産品設計原則：

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

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

在筆者接觸的B端産品設計中，組織架構的劃分就是按照成本組織和收入組織來規劃的，嚴格匹配企業的戰略目标，當目标發生變更，組織中資源的分配就會随之調整，所以産生了組織架構的新增和“删除”。（問題中學員提出的“禁用組織架構”其實也有誤差，應該是使組織架構失效，因為組織架構的變更通常是有規劃進行的，不是突然發生的事件。）

在某個組織被變更後，組織内産生的成本和收入依然會進入财務體系核算，不宜删除，人員作為成本的一部分，數據自然也要保留在系統中。

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

回到産品設計本身，我們有一個原則是一次隻做一件事情，産品架構的設計要符合低耦合的原則。

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

唠唠叨叨寫了這麼多，最後來個總結：

1. 高頻新增和非核心、低耦合的數據，使用删除功能；
2. 業務的耦合度高（數據有變更也會對其他業務産生影響需要保留的情況下）采用“禁用、停用、作廢”來做數據的删除；
3. 在禁用的基礎上，如果數據有明确的截止時間，可通過調整失效時間來提前做數據規劃或“删除”。

本文由@RaRa 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自unsplash，基于 CC0 協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,