Muyangmin

**See this issue by accident……** if you're still in trouble of this, maybe another log library [Android-PLog](https://github.com/Muyangmin/Android-PLog) may help you.:smile:

> 声明：本条仅作抛砖引玉之讨论，仅供参考。本人对该功能持中立态度。 我觉得这个需求是不是还欠讨论… ### 必要性 > > 1、唯一索引无法使用。 > 2、大部分读操作（如果只是单表，自然没有问题；但对复杂报表、多表关联极其不友好）都需要过滤掉处于删除状态的记录。 > 3、开发人员无脑乱用。业务上的冻结、失效，本就应该和逻辑删除严格区分，不能用逻辑删除的概念去表达冻结、失效。比如人员离职，我们不会把员工删除，应该是要用一个字段表示离职这个状态，但是有些开发人员无脑用逻辑删除。 > 4、（我目前更多的场景）对于企业系统来说， 已经审批通过的记录，一般就不会提供删除功能。未审批的，草稿状态，都是人工录进去的，删掉了的后果也就是重新录入一次。 我觉得**前两条**是真实存在的痛点，但是后面两个嘛……更多属于业务和代码规范层面的东西。因为部分开发人员的滥用（实际上是偷懒）就砍掉功能或者大改内部实现，会不会有点奇怪 :grin: ### 安全性 按我个人的经验和理解，逻辑删除的备份属性有两层： 1. **归档**，即证明某些数据历史上产生过，可在必要的时候追溯到； 2. **防丢失**，即在因为业务或技术原因误删除后可以找回数据。 如果采用楼主说的主动式回收站（即显式指定哪些数据可被回收），很显然功能 `1` 可以被保留，但功能 `2` 却可能部分或完全丧失，因为开发过程中可能*无法预见*哪些数据会被误删除。那么如果某些数据因此永久丢失了，逻辑删除的意义也就不存在了，数据安全很成问题。 >...

Thanks for your detailed response. From the previous investigation, I can confirm that the information from SBA itself can be updated in a timely manner. Your reply has given me...

I'm sorry for the delayed response. After carefully rechecking our program, we found that in some very rare scenarios, our update operation would fail, and there was no exception handling...