软删除是个好主意还是坏主意?
与其在数据库中真正删除一条记录,你可以将其标记为IsDeleted = true
,当恢复该记录时,只需将其标记为False
。
这是个好主意吗?
是否更好的做法是物理删除记录,然后将其移到归档数据库中,如果用户需要该记录,则软件会在归档中查找记录并重新创建它?
软删除是个好主意还是坏主意?
与其在数据库中真正删除一条记录,你可以将其标记为IsDeleted = true
,当恢复该记录时,只需将其标记为False
。
这是个好主意吗?
是否更好的做法是物理删除记录,然后将其移到归档数据库中,如果用户需要该记录,则软件会在归档中查找记录并重新创建它?
然而,这样做是有代价的,因为您需要更新查询和索引以排除已删除的行。
也许,不要切换标志,而是将其移动到另一个“垃圾桶”表中。
此外,有人可能会说,这只是一个部分解决方案,因为它仅涵盖了删除操作,但当您更新一行时,仍会覆盖旧值。
总的来说,我认为除非您确实必须这样做,否则永远不要删除任何内容。如今,磁盘空间很便宜。当然,存在某些限制,例如您有法律义务擦除某些数据,有些数据并不是那么重要,也许您不需要将旧数据在线上和同一张表中保留(在某个归档位置也可以)。
只是想加入一点。我总是采用软删除,虽然会影响性能,但非常轻微。考虑一下成本,如果您的客户抱怨在执行某些操作后,她甚至记不起来,您的软件停止工作了,那么这就是一个很好的例子。嗯,这可能是一个夸张的例子,但你永远不知道出了什么问题,谁做了什么,在之前发生了什么以及之后插入了什么。在这种情况下,它会派上用场。这个功能对审计目的非常有用,许多客户要求此类审计报告。
此外,在大多数基于工作流的应用程序中,客户对于在工作项上执行的“操作”感兴趣,例如分配了哪些值和谁处理了它等等,因此它成为一个软件特性/要求。
我是软删除的粉丝。主要是为了防止级联删除。但是,如果您正在选择子对象,则需要编写附加代码,它将连接到父(和所有父!)对象,以确保没有任何对象被删除。或者,您可以级联软删除,但是如果稍后要恢复它们,则可能不知道哪些子项已被删除,哪些是因为级联而被删除。
此外,我在每个对象上保留修订日期时间和修订用户名,以便我知道是谁最后修改(或软删除)了它。然后,对于审计跟踪,我创建一个 *History(如CustomerHistory)表,它在原始表的每次更新后插入。这样,在修改或软删除对象之后,我就有了执行操作的记录以及对象的最后已知状态。
我在以下广泛的情况下遇到了软删除:
CASE 1:将记录从用户/代码可见性中删除,但在数据库级别保留该记录,因为业务有兴趣知道它拥有那些记录。
这些要求大多由业务驱动,并且通常核心是法律要求(例如@joshperry和@armandino的情况),必须在数据库中保留先前的记录并为每个更改创建新记录。此时,我会查看CASE 2并评估是否满足要求,然后再添加IsDeleted标志
CASE 2:审计跟踪以跟踪记录的演变-有许多在线文章可以保留数据库中记录的审计跟踪
希望对你有所帮助。
IsDeleted
属性。结果频繁出现错误。问题很明显:每个普通用户想要针对该表运行的查询都涉及到“未删除”的数据,这意味着几乎99.9%的查询涉及到该表都必须在它的WHERE
子句中添加...AND IsDeleted = 'N'
。自然而然,这常常被省略:不论是编写代码的人忘记了添加它,还是根本不知道他们必须首先添加它。当然,在原始规范中没有这个要求,编写代码的人是在使用他们的主观判断力… - onedaywhen