数据库设计时应该考虑的问题（一）

数据库设计时应该考虑的问题（一）

数据删除是逻辑删除还是物理删除？

物理删除：指文件存储所用到的磁存储区域被真正的擦除或清零，这样删除的文件是不可以恢复的，物理删除是计算机处理数据时的一个概念。如果在数据库中直接使用delete、drop删除了表数据，如果没有备份的话，数据就很难恢复了。

逻辑删除（软删除）：逻辑删除就是对要被删除的数据打上一个删除标记，通常使用一个is_deleted字段标示行记录是不是被删除（或者使用一个status字段代表所谓的“删除”状态），在逻辑上是数据是被删除的，但数据本身是依然存在的。

区别：

物理删除一定程度上删除了暂时“无用”的数据，降低了表的数据量，对性能肯定是有好处的；但是如果没有备份的话，数据很难恢复。

逻辑删除恢复的话只要修改is_deleted等类似的状态标示字段就可以了，但是表的数据量肯定会比物理删除增加了，并且查询时经常要考虑到is_deleted字段，对索引都会有影响。

其实大多数业务场景中，很多“删除”操作对应的都是一个状态，比如商品现在下架了，以后可能还会上架；员工此次离职了，以后说不定还会“二进宫”，又回老东家上班等等，并且数据往往是很有价值的。从目前来看，我本人还是不支持直接使用物理删除，尤其是对业务核心表。其实如果使用物理删除的话，可以把删除的数据放到一个历史表（或者叫日志表）里面去，这样不至于数据完全丢失。像金融证券行业的数据库设计，有的采用交易表和若干张历史表的设计，每天使用数据迁移工具在闲时对闲联机日志表按日期进行转移，如果有关联交易就注意下日切问题同时查联机表和历史表，历史表对更早的数据就通过数据整理规约进数据仓库。不过这种金融证券场景跟主流的互联网场景，个人感觉跟主流的互联网公司的业务场景不是太一致，总之，目前采用逻辑删除的设计还是多一些的吧。

灵颖桥人–原文链接