物理删除与逻辑删除（硬删除与软删除）的数据库记录？
物理删除与逻辑删除（硬删除与软删除）的数据库记录？
已关闭。这个问题是基于观点的。它目前不接受答案。
想要改进这个问题？通过 编辑这个帖子 来更新问题，以便可以用事实和引用来回答。
改进这个问题
将记录标记为删除（即设置一个标记表示该记录已删除）与实际/物理删除记录相比，有什么优点？
这是一个常见的做法吗？
这是安全的吗？
admin 更改状态以发布 2023年5月22日
逻辑删除是常见做法吗？是的，我在很多地方看到它们被应用。它们安全吗？这真的取决于它们是否比在删除之前的数据更不安全。
当我还是一个技术领导时，我要求我们的团队保留所有数据，我知道我们会使用所有这些数据来构建各种BI应用程序，尽管当时我们不知道需求是什么。虽然从审计、故障排除和报告的角度来看这是好的（这是针对B2B交易的电子商务/工具网站，如果有人使用了工具，我们希望记录下来，即使他们的账户稍后被关闭），但它确实有几个缺点。
缺点包括（不包括其他已经提到的）：
- 保留所有数据的性能影响，我们要开发各种存档策略。例如，应用程序的某个区域每周产生大约1GB的数据。
- 保留数据的成本会随着时间的推移增加，尽管磁盘空间很便宜，但在线和离线管理TB级数据所需的基础设施量很大。它需要大量的磁盘冗余和人力，以确保备份正在迅速移动等。
在决定使用逻辑删除、物理删除或存档时，我会问自己以下问题：
- 这是可能需要重新插入到表中的数据。例如，用户账户适合这个类别，因为您可能会激活或停用用户账户。如果是这种情况，逻辑删除是最合适的。
- 存储这些数据有任何内在价值吗？如果有，会产生多少数据。根据这个条件，我会选择逻辑删除或实施存档策略。请记住，您始终可以在逻辑删除的记录上进行存档。
优点是您可以保留历史记录（用于审计），并且无需担心删除对数据库中引用要删除行的各个其他表的级联影响。缺点是您必须编写任何报告/显示方法以考虑标识。
关于它是否是常见做法 - 我会说是，但是像任何其他事情一样，您是否使用它取决于您的业务需求。
编辑：发现另一个缺点 - 如果您在表上有唯一索引，则删除的记录仍将占用“一个”记录，因此您也必须围绕该可能性进行编码（例如User表，具有唯一索引的用户名;一个已删除的记录仍将阻止删除用户的用户名用于新记录。要解决此问题，您可以在已删除的用户名列中附加GUID，但这是一个非常笨拙的解决方法，我不建议使用。在那种情况下，最好只有一条规则，即一旦使用用户名，就永远不能替换它。）