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

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

 

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

 

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

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

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

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

 

二、什么是反范式?

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

 

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

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

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

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

 

数据冗余规范:

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

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

(思考:还有哪些需要注意的点?)

 

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

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

 

五、反范式设计的优势

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

   2. 降低开发复杂度

 

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

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

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

 

最后:

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

 

 

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

 

(0)
上一篇 2022年3月21日
下一篇 2022年3月21日

相关推荐