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。