系统设计话题

1. 删除的记录

今天在做系统开发的时候，用户提了一个support case，说不小心把系统中的一个人删掉了，想要恢复回去，我查了下，这个人并没有被删掉，DB里面有一个status字段，值为deleted。感觉这样的设计很好呀，很好的把数据保留了下来，数据很容易恢复。

但我随后又稍微深入想了下，这样也有缺点，如果这条数据确实就是删除以后再也不会用的，这岂不是冗余数据，会增加DB的占用，以及降低搜索效率等等。所以一定要想好哪些数据要保留历史数据，保存多久，哪些模块不需要保留数据等等。如何设计这些也是一个点，可以多想想。

突然想到读写分离模型，不过不懂，之后可以研究下，还有sql index等。

2. 容易漏掉虚拟删除的情况

今天在查系统一个问题的时候，发现某条sql预想结果是一条，结果发现结果是两条，除了id其他内容都相同。然后查了下几张join的表，发现某一个表中有两条记录，只不过有一条记录，被标记为deleted。但代码中并没有过滤这样的情况，导致出错。我同事说这也是系统设计存在一定的问题，因为在写sql join的时候，习惯性的很少会考虑到被deleted的情况，尤其是这个程序员还是新手。所以觉得这种数据可以在删除的时候，放到log表中，这样以后想恢复的时候也可以恢复（记录的详细些），而且可以避免这种问题，因为这很难被测试出来，只有在特定情况下才会出现这种问题，而且没仔细检查的话，会导致数据错误而且不被发现，从而导致业务混乱。

补充下，今天刚刚发现被deleted的数据行也有一定用处，有可能是比较基础的模块数据，被其他功能所引用，通过id进行关联，可能过一段时间，这条数据被删除，其他功能的数据还在。如果物理删除这条数据，就有可能导致其他功能的数据出现缺失或者其他问题，学到了。

3. 用什么来记录log

最近在处理一个系统的问题时，发现一个系统使用了excel(2003)用来记录log，导致在经过一段时间后，excel被写满(6w多条记录)，然后不断发alert email。另外还听说其他系统有出现log文件是txt，然后写了几十个G，导致support时log很难打开、浏览和定位。目前觉得还是要把相关log记录在数据库表中。或者稍微一般的做法，也是每天或者每几天写一个txt作为log。