【MySQL性能优化】数据库设计三大范式(二)

蔚落 2022-05-21 01:49 204阅读 0赞

转载自http://chenhaoxiang.cn/2018/02/04/2158/

数据库设计无非遵循的就是减少冗余量，第二点就是遵循三范式

# 第一范式(1NF) #

确保每一列的原子性

也就是如果每一列都满足是不可再分的最小数据单元，则满足第一范式

比如  
id name sex address  
1 chx 0 湖南长沙

在这里，其实地址这个字段是可以再拆分的，拆分成省份，市区。  
但是，在有的场景下，也可以不分。  
需要根据具体的需求来看是否需要拆分  
这里的保证原子性，具体看业务需求  
如果仅仅只是起字符串的作用，在这里的地址，就可以不分。  
加入是电商项目，需要分地区等等收货地址，在这里就可以再分细一些

# 第二范式(2NF) #

主要是保证唯一  
如果一个关系满足一范式，并且除了主键以外的其他列，都依赖于该主键，则满足第二范式。

通俗来讲，就是每一个表有且仅有一个主关键字，其他数据与主关键字一一对应。注意，这里的主关键字肯定是主键，但是主键不一定是主关键字。  
参考百度百科:[第二范式][Link 1]

一般订单表中，我们都不会用id来作为订单号  
如果需要订单号，我们就要建一个orderid列  
这样也是为了安全性着想。项目内部是用id进行通讯的，而外部，我们就使用orderid来进行通讯  
另外就是，在分布式系统中，解决并发生成订单号  
比如，抢票分布式系统中，如何保证订单号不会重复生成(也就是怎么保证订单的幂等性)  
提前将订单号生成好，存放在redis中，在需要的时候，直接去redis中去取。这样就可以保证订单的幂等性

# 第三范式(3NF) #

指表中的所有数据元素不但要能惟一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。

其实理解起来就是不要有冗余数据  
比如:  
学号 姓名 所在系 系名称 系地址  
在这里学号决定各个属性，由于是单个关键字，没有部分依赖的问题，肯定是2NF。但是却有大量的数据冗余，有关学生的所在系 系名称 系地址。

所以可以将一个表拆分为两个表  
学号 姓名 所在系 和 所在系 系名称 系地址

注意这两个表之间的联系在所在系这个外关键字

不过有点时候，不一定要完全遵循第三范式  
有的时候，为了业务需求，完全可以接收一些数据的冗余  
比如一些视频网站。  
课程表：  
课程id 课程name 浏览量  
1 java 2000

课程详情表：  
详情id 详情name 详情浏览量 课程id  
1 java基础1 1000 1  
1 java基础2 1000 1  
前面课程表如果没有浏览量，每次都需要查询详情表的sum，这样效率非常低，这个时候就可以在课程表增加一个浏览量字段

所以说，没有死的设计，只有具体的需求

虽然市面上还有4NF，5NF，但是主流还是3NF，其他的，有兴趣的朋友可以自己搜索了解一下

本文章由[\[谙忆\]][Link 2]编写， 所有权利保留。  
欢迎转载，分享是进步的源泉。

[Link 1]: https://baike.baidu.com/item/%E7%AC%AC%E4%BA%8C%E8%8C%83%E5%BC%8F/3193760?fr=aladdin
[Link 2]: http://chenhaoxiang/