B端产品的设计，几乎都是在围绕新增、删除、修改、查询、显示、计算、传输、业务流做工作，而增删改查是原型设计中基础的基础。“删除”数据的方式有删除、禁用、失效，那么，选择的逻辑是什么呢？本文作者分享了自己的看法，一起来看一下吧。

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. 在禁用的基础上，如果数据有明确的截止时间，可通过调整失效时间来提前做数据规划或“删除”。