一尘不染

从不删除条目?好主意?通常?

mysql

我正在设计一个系统,但我认为让最终用户删除数据库中的条目并不是一个好主意。我认为是这样,因为最终用户常常被授予管理员权限,最终可能使数据库混乱,然后求助于我修复它。

当然,如果将它们设置为admin,他们将需要能够删除条目或至少认为它们确实如此。

因此,我当时认为数据库中的 所有 条目都应有一个“活动”字段。如果他们尝试删除条目,则只会将标志设置为“
false”或类似的内容。然后会有某种超级管理员可以成为我公司的团队来改变这个领域。

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

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


阅读 311

收藏
2020-05-17

共1个答案

一尘不染

在我们的数据库之一中,我们区分了transactionaldictionary记录。

简而言之,transactional记录是您在现实生活中无法回滚的事情,例如来自客户的呼叫。您可以更改呼叫者的姓名,状态等,但是您无法关闭呼叫本身。

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

Transactional记录 和导致 记录的 事物 从未删除,而记录dictionary可以被删除。

所谓“导致它们的事物”,是指该记录一旦出现在可导致transactional记录的业务规则中,该记录也将变为transactional

就像,city可以从数据库中删除。但是,当出现一条规则说“向
莫斯科的*SMS所有客户发送”时,城市也将成为记录,否则我们将无法回答“为什么发送此消息”的问题。
*transactional``SMS

区别的经验法则是: 这仅仅是我公司的业务吗?

如果我的一名员工基于数据库中的数据做出了决定(例如,他做出了基于某项管理决策的报告,然后该数据报告基于消失了),则删除这些数据被认为是可以的。

但是,如果该决定影响到客户的一些立即行动(例如打电话,打乱客户的余额等),那么导致这些决定的一切都会永远保留。

它可能因一种业务模型而异:有时甚至可能需要记录内部数据,有时可以删除影响外界的数据也可以。

但是对于我们的业务模型,上述规则行之有效。

2020-05-17