物理与逻辑/软删除数据库记录？

Question

执行逻辑/软删除记录(即设置一个表明记录被删除的标志)而不是实际或物理删除记录的优点是什么？

这是常见做法吗？

这样安全吗？

Answer 1

优点是您保留历史记录(适用于审计),并且您不必担心通过引用要删除的行的数据库中的各种其他表级联删除.缺点是您必须编写任何报告/显示方法以将标记考虑在内.

只要这是一种常见的做法 - 我会说是的,但与使用它的任何事情一样,取决于您的业务需求.

编辑:想到另一个不利因素 - 如果表上有唯一索引,删除的记录仍将占用"一"记录,因此您必须围绕这种可能性进行编码(例如,具有唯一索引的用户表)用户名;已删除的记录仍然会阻止已删除的用户用户名以获取新记录.解决这个问题,您可以使用已删除的用户名列的GUID,但这是一个非常hacky的解决方法,我不建议.可能在这种情况下它会最好只有一个规则,一旦使用用户名,它永远不会被替换.)

Answer 2

逻辑删除是否常见？是的,我在很多地方都见过这个.他们安全吗？这真的取决于它们在您删除数据之前的数据是否安全性较低？

当我担任技术主管时,我要求我们的团队保留每一段数据,当时我知道我们将使用所有数据来构建各种BI应用程序,尽管当时我们不知道要求是什么是.虽然从审计,故障排除和报告的角度来看这很好(这是B2B交易的电子商务/工具网站,如果有人使用工具,我们想要记录它,即使他们的帐户后来被关闭),它确实有几个缺点.

缺点包括(不包括已经提及的其他人):

1. 保持所有数据的性能影响,我们制定各种归档策略.例如,应用程序的一个区域接近每周生成大约1Gb的数据.
2. 保持数据的成本确实随着时间的推移而增长,而磁盘空间便宜,在线和离线保存和管理数据量的基础设施数量很多.冗余需要大量磁盘,人们有时间确保备份快速移动等.

在决定使用逻辑,物理删除或存档时,我会问自己这些问题:

1. 是否需要将此数据重新插入表中.例如,用户帐户适合此类别,因为您可能激活或停用用户帐户.如果是这种情况,则逻辑删除最有意义.
2. 存储数据有什么内在价值吗？如果是这样,将生成多少数据.根据这一点,我要么采用逻辑删除,要么实施归档策略.请记住,您始终可以归档逻辑删除的记录.

Answer 3

可能有点晚了但我建议大家查看Pinal Dave关于逻辑/软删除的博文:

我根本不喜欢这种设计[软删除].我坚信只有必要数据应该在单个表中并且无用数据应该移动到存档表的体系结构.我没有关注isDeleted列,而是建议使用两个不同的表:一个包含订单,另一个包含已删除的订单.在这种情况下,您将不得不维护两个表,但实际上,它很容易维护.将UPDATE语句写入isDeleted列时,将INSERT INTO写入另一个表并从原始表中删除它.如果情况是回滚,则以相反的顺序写入另一个INSERT INTO和DELETE.如果您担心事务失败,请将此代码包装在TRANSACTION中.

在上述情况下,较小的表与较大的表有什么优点？

• 较小的桌子易于维护
• 索引重建操作要快得多
• 将存档数据移动到另一个文件组将减少主文件组的负载(考虑到所有文件组都在不同的系统上) - 这也将加快备份速度.
• 由于规模较小,统计数据将经常更新,这将减少资源消耗.
• 索引的大小会更小
• 桌子的性能会随着桌子尺寸的缩小而提高.

Answer 4

我是一名NoSQL开发人员,在我上一份工作中,我使用的数据对于某人来说一直很重要,如果在创建的同一天意外删除了,我无法在上次备份中找到它从昨天!在那种情况下,软删除总能保存这一天.

我使用时间戳进行软删除,注册文档被删除的日期:

IsDeleted = 20150310  //yyyyMMdd

每个星期天,一个进程走在数据库上并检查该IsDeleted字段.如果当前日期和时间戳之间的差异大于N天,则文档被硬删除.考虑到文档仍然可以在某些备份中使用,这样做是安全的.

编辑:这个NoSQL用例是关于在数据库中创建的大文档,每天数十或数百个,但不是数千或数百万.通常,它们是具有工作流程的状态,数据和附件的文档.这就是为什么用户可能删除重要文件的原因.此用户可能是具有管理员权限的用户,也可能是文档的所有者,仅举几例.

TL; DR我的用例不是大数据.在这种情况下,您将需要一种不同的方法.

Answer 5

我使用的一种模式是创建一个镜像表并在主表上附加一个触发器,因此所有删除(如果需要,还会更新)都会记录在镜像表中.

这允许您"重建"已删除/更改的记录,您仍然可以在主表中进行硬删除并保持"干净" - 它还允许创建"撤消"功能,您还可以记录日期,时间,以及在镜像表中执行操作的用户(在搜寻情况下非常有用).

另一个优点是,在查询主数据库时,没有机会意外地包含已删除的记录,除非您故意在镜像表中包含记录(您可能希望显示实时和已删除的记录).

另一个优点是镜像表可以独立清除,因为它不应该有任何实际的外键引用,与从使用软删除的主表清除相比,这仍然是一个相对简单的操作,但仍然具有与其他表的引用连接.

还有什么优点？ - 如果你有一群编程人员在项目上工作,使用混合技能读取数据库并注意细节级别,那就太好了,你不必熬夜,希望他们中的一个不忘记不包括删除记录(lol,Not Include Deleted Records = True),这导致夸大的事情说客户可用的现金头寸,然后他们购买一些股票(即,在交易系统中),当你使用交易系统时,你我们会很快发现稳健解决方案的价值,即使它们可能有更多的初始"开销".

例外: - 作为指南,对"参考"数据(如用户,类别等)使用软删除,对"事实"类型数据(即事务历史)使用镜像表进行硬删除.

Answer 6

我通常使用逻辑删除 - 我发现它们在您间歇性地将“已删除”数据存档到存档表（如果需要可以搜索）时运行良好，因此不会影响应用程序的性能。

它运作良好，因为如果您接受过审计，您仍然拥有数据。如果你物理删除它，它就消失了！

Answer 7

我是逻辑删除的忠实拥护者，尤其是对于“业务线”应用程序或用户帐户而言。我的理由很简单：通常我不希望用户再使用该系统（因此，该帐户被标记为已删除），但是如果我们删除该用户，我们将失去所有工作。

另一个常见情况是，删除用户后可能会重新创建用户。对于用户来说，将其所有数据保持原样显示（而不是重新创建）是一种更好的体验。

我通常认为删除用户更多是无限期地“暂停”他们。您永远不知道他们什么时候会合法地回来。

Answer 8

我曾经做软删除，只是为了保留旧记录。我意识到用户并不像我想象的那样经常查看旧记录。如果用户想查看旧记录，他们可以从存档或审计表中查看，对吗？那么，软删除有什么好处呢？它只会导致更复杂的查询语句等。

在我决定不再软删除之前，以下是我已经实施的内容：

1. 实施审计，记录所有活动（添加、编辑、删除）。确保没有外键链接到审计，并确保该表是安全的，除了管理员之外没有人可以删除。

2. 确定哪些表被认为是“事务表”，哪些表很可能会被保留很长时间，并且很可能用户可能想要查看过去的记录或报告。例如; 购买交易。该表不应该只保留主表的 id（如 dept-id），还应保留其他信息，如名称作为参考（如 dept-name），或任何其他报告所需的字段。

3. 实现主表的“活动/非活动”或“启用/禁用”或“隐藏/显示”记录。因此，用户可以禁用/停用主记录，而不是删除记录。这种方式安全得多。

只是我的两分钱的意见。

Answer 9

我几乎总是软删除，原因如下：

• 如果客户要求您这样做，您可以恢复已删除的数据。软删除让客户更满意。从备份中恢复特定数据很复杂
• 检查isdeleted无处不在不是问题，userid无论如何您都必须检查（如果数据库包含来自多个用户的数据）。您可以通过将这两个检查放在单独的函数上（或使用视图）来强制执行代码检查
• 优雅的删除。处理已删除内容的用户或进程将继续“看到”它，直到他们点击下一次刷新。如果进程正在处理一些突然删除的数据，这是一个非常理想的功能
• 同步：如果您需要设计数据库和移动应用程序之间的同步机制，您会发现软删除更容易实现