标签：ima roc 过程 开发 数据 ESS 主键 第一范式 规范
数据库反范式设计是一个老生常谈的话题，最近两年我用的也确实非常多,我个人觉得合理的反范式设计才是更合理的设计，严格的范式设计在某种程度上会加大开发的复杂度，并且带来性能上的耗损
对于反范式的优劣势，欢迎大家留言讨论
一、关系数据库三大范式回顾
第一范式：原子性，每一列都是不可分割的
第二范式：每个表必须有一个主键、唯一标识
第三范式：说的就是减少冗余字段、增加外键关系
二、什么是反范式？
不完全满足以上范式的设计过程就是反范式设计
三、常见的反范式设计 - 合理冗余
(思考：冗余会带来哪些问题?)
冗余可能是用的最多也是最能立竿见影的方式了，在数据库范式规范中，提倡我们尽量减少冗余，但实际工作下来，觉得合理的冗余将极大的提升查询性能，并给开发工作带来了极大的便利
如上图，是我常用的伎俩，在存储操作人、省市区等信息的时候，我常常会将对应的名称也存储起来， 省去了多表联查，提升了性能
数据冗余规范：
1. 变更频率小或者不变更的内容，如省市区、姓名、行业等；
2. 冗余数据不能过大，如果表占用空间过大，反而降低查询性能
(思考：还有哪些需要注意的点？)
四、常见的反范式设计 - 去除外键
在范式设计中，对于两个表的关联，要求我们需要建立外键关系，但实际工作中，我们在设计时常常去除了这一点，对于数据的完整性和一致性都是通过程序来处理
五、反范式设计的优势
1. 减少多表联查，提升查询性能
2. 降低开发复杂度
六、反范式设计带来的问题：
1. 数据一致性问题，对于冗余数据一旦发生变更，维护起来将是一件麻烦的事情(目前还没有遇到这类问题，偶尔出现姓名更改，但如果把姓名冗余当做快照来看待也没问题)
2. 增加磁盘空间占用，冗余数据将会占用额外的磁盘空间 (也就是空间换时间的概念)
最后：
大家结合自身实际情况，切不可盲目参照，合理使用，对于反范式设计的想法，欢迎大家留言区讨论
相关资源获取或其他疑问可在公众号CodeL留言。
标签：ima roc 过程 开发 数据 ESS 主键 第一范式 规范
原文地址：https://www.cnblogs.com/codelir/p/9988253.html
