从不删除条目?好主意?通常? [英] Never delete entries? Good idea? Usual?

问题描述

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

I am designing a system and I don't think it's a good idea to give the ability to the end user to delete entries in the database. I think that way because often then end user, once given admin rights, might end up making a mess in the database and then turn to me to fix it.

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

Of course, they will need to be able to do remove entries or at least think that they did if they are set as admin.

因此，我当时认为数据库中的所有条目应具有活动"字段.如果他们尝试删除条目，则只会将标志设置为"false"或类似的内容.然后会有某种超级管理员可以成为我公司的团队来更改此字段.

So, I was thinking that all the entries in the database should have an "active" field. If they try to remove an entry, it will just set the flag to "false" or something similar. Then there will be some kind of super admin that would be my company's team who could change this field.

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

I already saw that in another company I worked for, but I was wondering if it was a good idea. I could just make regular database backups and then roll back if they commit an error and adding this field would add some complexity to all the queries.

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

What do you think? Should I do it that way? Do you use this kind of trick in your applications?

推荐答案

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

In one of our databases, we distinguished between transactional and dictionary records.

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

In a couple of words, transactional records are things that you cannot roll back in real life, like a call from a customer. You can change the caller's name, status etc., but you cannot dismiss the call itself.

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

Dictionary records are things that you can change, like assigning a city to a customer.

Transactional记录及其导致的记录从未删除，而dictionary记录则可以删除.

Transactional records and things that lead to them were never deleted, while dictionary ones could be deleted all right.

通过导致它们的事物"，我的意思是，只要该记录出现在业务规则中并可能导致transactional记录，该记录也将变为transactional.

By "things that lead to them" I mean that as soon as the record appears in the business rules which can lead to a transactional record, this record also becomes transactional.

例如，可以从数据库中删除city.但是，当出现一条规则说向莫斯科的所有客户发送SMS"时，城市也成为了transactional记录，否则我们将无法回答问题为什么此SMS发送".

Like, a city can be deleted from the database. But when a rule appeared that said "send an SMS to all customers in Moscow", the cities became transactional records as well, or we would not be able to answer the question "why did this SMS get sent".

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

A rule of thumb for distinguishing was this: is it only my company's business?

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

If one of my employees made a decision based on data from the database (like, he made a report based on which some management decision was made, and then the data report was based on disappeared), it was considered OK to delete these data.

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

But if the decision affected some immediate actions with customers (like calling, messing with the customer's balance etc.), everything that lead to these decisions was kept forever.

从一种业务模型到另一种业务模型可能有所不同:有时甚至可能需要记录内部数据，有时可以删除影响外界的数据.

It may vary from one business model to another: sometimes, it may be required to record even internal data, sometimes it's OK to delete data that affects outside world.

但是对于我们的业务模型，上面的规则行之有效.

But for our business model, the rule from above worked fine.

这篇关于从不删除条目?好主意?通常?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！