如here所述，比较因素在下面列出。您可以根据以下因素自行决定

易于设置

• 软删除更容易实现，因为它仅涉及更新 一列，而硬删除也将涉及将数据复制到 删除到审核表中。

  

优点：软删除

调试

• 通过“软删除”，可以轻松调试数据问题，原因是 Deleted_flag但是通过Audit表进行调试也很容易 可能。所以这很重要。

  

优势：不适用

恢复数据

• 通过软删除恢复“删除”的数据非常容易，因为 它只是涉及到取消设置Deleted_flag。
• 但是请注意，恢复数据的情况极为罕见。

  

优点：软删除

查询活动数据

• 根据经验，我可以说，当 开发人员忘记了在条件中添加“ delete_flag = 0”条件 选择由于哪些问题引起的查询。
• 如果您将带有Doctrine之类的ORM与“软删除”插件一起使用 启用，那么这将不是问题，因为ORM负责 添加此支票。

  

优点：很难删除

查看简单性

• 将表中的所有数据作为活动数据与视图相关 简单（所见即所得-所见即所得）
• 在“硬删除”中，所有“已删除”的数据只会显示在审核中 表格，而系统中的其余表格将处于“活动”状态 数据。因此，存在针对硬删除的关注点分离。

  

优点：很难删除

操作性能

• 更新比删除（微秒）要快
• 因此，从技术上讲，软删除应该比硬删除（ 还可以考虑插入审核表）。

  

优点：软删除

应用程序性能

• 速度
  • 要支持软删除，所有选择查询都必须具有条件 ‘WHERE delete_flag = 0’。
  • 在涉及JOIN的情况下，将会有多个这样的情况 条件。条件较少的选择查询比 有条件的人。

  

优点：很难删除

• 大小
  • 为了支持更快的软删除，我们需要为每个索引都有一个索引 每个表中的delete_flag
  • 另外，由于表格具有 “软删除”数据+有效数据。
  • 随着表大小的增加，查询会变慢。

  

优点：很难删除

数据库功能兼容性 唯一索引

• 唯一索引可通过防止多个索引来确保数据完整性 在数据库级别出现了一行。
• 具有软删除功能可防止使用唯一索引。
• 此外，我们无法更新A1-B1的旧软删除条目 因为这将意味着重写一些数据，从而导致丢失 记录的数据（例如：更新日期时间或某些其他的delete_by列 如果存在）

  

优点：很难删除

级联

• 对于软删除，我们无法使用“按删除”级联。的 另一种方法是创建一个“ UPDATE”触发器来跟踪

  

优点：很难删除