永远不删除条目?好主意?通常?

mar*_*cgg 18 mysql

我正在设计一个系统,我不认为让最终用户删除数据库中的条目是一个好主意.我认为这样,因为通常最终用户,一旦获得管理员权限,最终可能会在数据库中弄乱,然后转向我修复它.

当然,他们需要能够删除条目,或者至少认为如果他们被设置为管理员,他们会这样做.

所以,我认为数据库中的所有条目都应该有一个"活动"字段.如果他们试图删除一个条目,它只会将标志设置为"false"或类似的东西.然后会有某种超级管理员,这将成为我公司的团队,可以改变这个领域.

我已经在我工作的另一家公司看到过,但我想知道这是不是一个好主意.我可以只进行常规数据库备份,然后如果它们提交错误就回滚,添加此字段会增加所有查询的复杂性.

你怎么看?我应该这样做吗?你在你的应用程序中使用这种技巧吗?

Qua*_*noi 15

在我们的一个数据库中,我们区分transactional和dictionary记录.

有几个词,transactional记录是你无法在现实生活中回滚的东西,比如来自顾客的电话.您可以更改呼叫者的姓名,状态等,但您无法解除呼叫本身.

Dictionary记录是您可以更改的内容,例如分配city给客户.

Transactional从未删除过导致它们的记录和事物,而dictionary可以删除那些记录和事物.

通过"导致它们的事物",我的意思是,一旦记录出现在可以导致transactional记录的业务规则中,该记录也会变为transactional.

比如,a city可以从数据库中删除.但是当一条规则出现"向莫斯科的SMS所有客户发送"时,这些城市也成了记录,或者我们无法回答"为什么要发送" 这个问题.transactionalSMS

区分的一个经验法则是:它只是我公司的业务吗?

如果我的一个员工根据数据库中的数据做出决定(比如,他根据某个管理决策做出了报告,然后数据报告基于消失了),那么删除这些数据就被认为是可以的.

但如果决定影响到与客户的一些直接行动(如打电话,弄乱客户的余额等),那么导致这些决定的一切都将永远存在.

它可能因商业模式而异:有时,甚至可能需要记录内部数据,有时可以删除影响外部世界的数据.

但对于我们的商业模式,上述规则运作良好.

  • 这当然是一种常见的做法,也是一个很好的用例,说明为什么你不会删除一些数据. (2认同)

Tad*_*ghe 10

人们做这样的事情有两个原因是审计和自动回滚.如果一行被完全删除,那么如果它出错,则无法自动回滚该删除.此外,保持一行及其先前的状态对于审核非常重要 - 超级用户应该能够看到谁删除了什么,什么时候以及谁更改了什么等等.

当然,这完全取决于您当前应用程序的业务逻辑.某些应用程序不需要审计,完全删除行可能是正确的.


Not*_*tMe 6

设置IsActive或DeletedDate等标志的缺点是,在提取数据时,所有查询都必须考虑该标记.这使得编写报告时,另一个程序员更有可能不小心忘记了这个标志......

稍微好一点的替代方法是将该记录存档到不同的数据库中.这样它就被物理地移动到通常不被搜索的位置.您可以添加几个字段来捕获谁删除它以及何时删除它; 但关键是它不会污染你的主数据库.

此外,您可以提供撤消功能,以便将其快速恢复; 并在30天或类似之后进行永久性删除.

关于意见的更新:

通过视图,数据仍然参与您的索引方案.如果可能删除的数据量很小,则视图可能很好,因为从编码角度来看它们更简单.