空间换时间之反范式设计之路/合理冗余/去除外键

Posted 2021-01-21 codelir

数据库反范式设计是一个老生常谈的话题，最近两年我用的也确实非常多,我个人觉得合理的反范式设计才是更合理的设计，严格的范式设计在某种程度上会加大开发的复杂度，并且带来性能上的耗损

 

对于反范式的优劣势，欢迎大家留言讨论

 

一、关系数据库三大范式回顾

第一范式：原子性，每一列都是不可分割的

第二范式：每个表必须有一个主键、唯一标识

第三范式：说的就是减少冗余字段、增加外键关系

 

二、什么是反范式？

不完全满足以上范式的设计过程就是反范式设计

 

三、常见的反范式设计 - 合理冗余

(思考：冗余会带来哪些问题?)

冗余可能是用的最多也是最能立竿见影的方式了，在数据库范式规范中，提倡我们尽量减少冗余，但实际工作下来，觉得合理的冗余将极大的提升查询性能，并给开发工作带来了极大的便利

如上图，是我常用的伎俩，在存储操作人、省市区等信息的时候，我常常会将对应的名称也存储起来， 省去了多表联查，提升了性能

 

数据冗余规范：

1. 变更频率小或者不变更的内容，如省市区、姓名、行业等；

2. 冗余数据不能过大，如果表占用空间过大，反而降低查询性能

(思考：还有哪些需要注意的点？)

 

四、常见的反范式设计 - 去除外键

在范式设计中，对于两个表的关联，要求我们需要建立外键关系，但实际工作中，我们在设计时常常去除了这一点，对于数据的完整性和一致性都是通过程序来处理

 

五、反范式设计的优势

   1. 减少多表联查，提升查询性能

   2. 降低开发复杂度

 

六、反范式设计带来的问题：

   1. 数据一致性问题，对于冗余数据一旦发生变更，维护起来将是一件麻烦的事情(目前还没有遇到这类问题，偶尔出现姓名更改，但如果把姓名冗余当做快照来看待也没问题)

   2. 增加磁盘空间占用，冗余数据将会占用额外的磁盘空间 (也就是空间换时间的概念)

 

最后：

大家结合自身实际情况，切不可盲目参照，合理使用，对于反范式设计的想法，欢迎大家留言区讨论

 

 

相关资源获取或其他疑问可在公众号CodeL留言。