MySQL数据库优化技术之数据库表的设计
三范式介绍
表的范式:只有符合的第一范式,才能满足第二范式,进一步才能满足第三范式。
1、 第一范式:
表的列具有原子性,不可再分解。只要是关系型数据库都自动满足第一范式。
数据库的分类:
关系型数据库:MySQL/ORACLE/Sql Server/DB2等
非关系型数据库:特点是面向对象或者集合
nosql数据库:MongoDB(特点是面向文档)
2、 第二范式:
表中的记录是唯一的,就满足第二范式。通常我们设计一个主键来实现。
主键一般不含业务逻辑,一般是自增的;
3、 第三范式:
表中不要有冗余数据,即如果表中的信息能够被推导出来就不应该单独的设计一个字段来存放;对字段冗余性的约束,要求字段没有冗余。
如下表所示,符合三范式要求:
student表
id | name | age | class_id |
1 | zhangsan | 27 | 1 |
2 | lisi | 28 | 2 |
class表
id | name |
1 | 1班 |
2 | 2班 |
如下表所示,不符合三范式要求:
student表
id | name | age | class_id | class_name |
1 | zhangsan | 27 | 1 | 1班 |
2 | lisi | 28 | 2 | 2班 |
class表
id | name |
1 | 1班 |
2 | 2班 |
反三范式案例:
一个相册下有多个图片,每个图片有各自的浏览次数,相册有总的浏览次数。
相册浏览表
id | name | views |
1 | aa | 100 |
2 | bb | 40 |
图片表:
id | name | img | views | owner |
1 | pic1 | pic1.jpg | 55 | 1 |
2 | pic2 | pic2.jpg | 45 | 1 |
3 | pic3 | pic3.jpg | 40 | 2 |
如果相册浏览表没有适当的冗余,效率有影响。
冗余比较可以得出一个结论:1对N时,冗余应当发生在1的一端。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。