转载自//02/04/2158/
数据库设计无非遵循的就是减少冗余量,第二点就是遵循三范式
第一范式(1NF)
确保每一列的原子性
也就是如果每一列都满足是不可再分的最小数据单元,则满足第一范式
比如
id name sex address
1 chx 0 湖南长沙
在这里,其实地址这个字段是可以再拆分的,拆分成省份,市区。
但是,在有的场景下,也可以不分。
需要根据具体的需求来看是否需要拆分
这里的保证原子性,具体看业务需求
如果仅仅只是起字符串的作用,在这里的地址,就可以不分。
加入是电商项目,需要分地区等等收货地址,在这里就可以再分细一些
第二范式(2NF)
主要是保证唯一
如果一个关系满足一范式,并且除了主键以外的其他列,都依赖于该主键,则满足第二范式。
通俗来讲,就是每一个表有且仅有一个主关键字,其他数据与主关键字一一对应。注意,这里的主关键字肯定是主键,但是主键不一定是主关键字。
参考百度百科:第二范式
一般订单表中,我们都不会用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,其他的,有兴趣的朋友可以自己搜索了解一下
本文章由[谙忆]编写, 所有权利保留。
欢迎转载,分享是进步的源泉。
如果觉得《【MySQL性能优化】数据库设计三大范式(二)》对你有帮助,请点赞、收藏,并留下你的观点哦!