用户现场素材丢失想到的一二三

用户购买我们的产品是希望借助于软件管理他们的资产，优化他们现有的工作流程。

软件只是一个辅助工具，素材资产才是他们最重要的东西。软件并不是他们最重要的东西。

当他们发现这个辅助工具会破坏，丢失他们的资产时，他们是很在乎的。

 

就像我们使用一个文件管理软件，百度云盘，有道云笔记或者说博客园一样，随着时光的流逝，我们也积累了大量的资产。

如果有一天你发现百度云盘上重要的资料，有道云上重要的随笔，博客园上的技术博客不见了。你是会很生气的。

 

那么，我们作业软件产品的生产者，如何避免破坏用户的资产呢。

 

第一，对于业务实体的删掉逻辑一定要谨慎，凡是存在删除的地方，在我们大脑中是清晰明白的。哪些地方有删掉接口，哪些地方会调用删除接口，删除的地方必须有日志记录，并且最好单独日志记录，并且这个日志不会被定期删掉。

不用考虑这些日志会占用空间。因为对我们来说几十，几百万的实体记录，用文本来记录，描述清楚，when ,who, at where , howto , do what. 一条记录也就100个字符，10条也行1K.  10000条也才1M,100万条也才100M. 

 

第二，对于DB的删除逻辑，在数据库脚本这块，一定要慎重。发给用户的更新脚本， 需要考虑这个操作对用户的已有数据有什么影响。调大或者调小字段长度。对用户现有的数据有何影响一定要考虑清楚

 

第三，对存储的删除逻辑，在DB里的逻辑实体通常是与存储上的文件对应的，一般情况下我们不应该直接操作操作存储上的文件。对存储上文件的操作都应该封装在逻辑实体的操作之中，比如对逻辑实体的更新，删除里才会去操作存储上的文件。

这样可以做到DB成存储的一致性。避免孤立的DB实体，以及孤立的存储文件存在。特别注意，以前出现过类似事情，在linux或者MAC上面 umount 存储挂载，然后 rm -rf 本地挂载节点 这种操作很危险，因为有可能第一步没有完成，导致删除掉了中心存储的文件

 

总之，当我们的产品交给用户之后，他就已经不再是我们的东西。超出了我们能控制的范围。因此一定要谨慎，避免破坏用户的资源，伤害用户的心情。