我正在设计一个系统,但我认为让最终用户删除数据库中的条目并不是一个好主意。我认为是这样,因为最终用户常常被授予管理员权限,最终可能使数据库混乱,然后求助于我修复它。
当然,如果将它们设置为admin,他们将需要能够删除条目或至少认为它们确实如此。
因此,我当时认为数据库中的 所有 条目都应有一个“活动”字段。如果他们尝试删除条目,则只会将标志设置为“ false”或类似的内容。然后会有某种超级管理员可以成为我公司的团队来改变这个领域。
我已经在我工作过的另一家公司看到了,但是我想知道这是否是个好主意。我 可以 进行常规的数据库备份,然后在它们提交错误时回滚,添加此字段会给所有查询增加一些复杂性。
你怎么看?我应该那样做吗?您在应用程序中使用这种技巧吗?
在我们的数据库之一中,我们区分了transactional和dictionary记录。
transactional
dictionary
简而言之,transactional记录是您在现实生活中无法回滚的事情,例如来自客户的呼叫。您可以更改呼叫者的姓名,状态等,但是您无法关闭呼叫本身。
Dictionary记录是可以更改的内容,例如将a分配city给客户。
Dictionary
city
Transactional记录 和导致 记录的 事物 从未删除,而记录dictionary可以被删除。
Transactional
所谓“导致它们的事物”,是指该记录一旦出现在可导致transactional记录的业务规则中,该记录也将变为transactional。
就像,city可以从数据库中删除。但是,当出现一条规则说“向 莫斯科的*SMS所有客户发送”时,城市也将成为记录,否则我们将无法回答“为什么发送此消息”的问题。 *transactional``SMS
SMS
transactional``SMS
区别的经验法则是: 这仅仅是我公司的业务吗?
如果我的一名员工基于数据库中的数据做出了决定(例如,他做出了基于某项管理决策的报告,然后该数据报告基于消失了),则删除这些数据被认为是可以的。
但是,如果该决定影响到客户的一些立即行动(例如打电话,打乱客户的余额等),那么导致这些决定的一切都会永远保留。
它可能因一种业务模型而异:有时甚至可能需要记录内部数据,有时可以删除影响外界的数据也可以。
但是对于我们的业务模型,上述规则行之有效。