MySQL 学习篇（四）数据库结构设计目的、基本字段类型介绍和实战内容
目录
数据库优化的目的
数据库结构设计的步骤
数据库设计范式
数据库第一范式
数据库第二范式
数据库第三范式
数据库设计的目的
实战
需求说明
需求分析及逻辑设计
需求分析及逻辑设计-反范式化设计
反范式化设计总结
范式化设计和反范式化设计优缺点
数据库的物理设计介绍
物理设计涉及的内容
定义数据库表、及字段命名规范
选择适合的存储引擎
物理设计-数据类型的选择
不同数据类型在Mysql服务器上的体现
如何选择VARCHAR和CHAR类型
应该如何确定VARCHAR的宽度
VARCHAR的实用场景
如何选择varchar和char类型
CHAR类型的适用场景
物理设计-如何存储日期类型
如何存储日期数据
timestamp在Mysql的时区不同的体现
datetime、timestamp是如何存储微秒值
查看timestamp自动更新特征
Timstamp数据结果操作结论
date类型和time类型
存储日期时间数据注意的事项
物理设计——本章节总结
存储引擎的最好选择
InnoDB存储引擎的选择注意事项
如何为Innodb选择主键
数据库设计的整个过程
-
数据库优化的目的
- 1 减少数据的冗余。
问：那么什么是数据冗余呢？
答：指相同的数据在多个地方的存在，或者说表中的某个列的，可以由其他列来计算得到，这样的数据就是冗余的。这里所说的，那是要尽量减少数据的冗余，而不是说要完全的没有冗余的数据，因为在一些情况下，必要的数据冗余也是必须的。
- 2 尽量避免在数据维护中出现的更新，插入以及删除异常。
- 3 节约数据库的存储空间
- 4 提高查询的效率
-
数据库结构设计的步骤
-
数据库设计范式
-
数据库第一范式
例子：
分析：
每一列不可拆分，所有列由基本的数据类型组成，是二维表（但是还是存在冗余【反范式】）
-
数据库第二范式
例子：show creat table selectcourse;
分析：学号课程名称组成符合组件，有可能不满足第二范式要求的，学分只和课程名称名称关联也就是上面的第二个，总结是不符合。
拆分成符合：
分成：《学分表》《课程表》《学生选课关系表》
show create table study\G
show create table course\G
前两种表只有一个主键so满足第二范式要求；
show create tablestudycourse\G
第三张表不存在非主键的依赖关系也是符合第二范式。
修改结果
已满足第二范式看是否满足第三范式。
-
数据库第三范式
例子：
分析：但是学院的地址和学院又有依赖关系，那就是说学院地址和学院具有传递依赖关系。
拆分改造：《学生信息表》《学院信息表》
结论：第三范式该造后不会有数据冗余和数据维护异常。
-
数据库设计的目的
-
实战
-
需求说明
按下面的需求，设计一个电子商务网站的数据结构
- 网站只销售图书类商品
- 需要具有以下功能（用户登录，商品展示，供应商管理，用户管理，在线销售）
-
需求分析及逻辑设计
用户登录及用户管理功能
- 用户必须注册并登录系统才能进行网上交易（用户名作为用户信息的业务主键）
- 同一时间，一个用户只能在一个地方登陆
- 用户信息：{用户名，密码，手机号，姓名，注册日期，在线状态，出生日期}
只有一个业务主键，一定是符合第二范式；
没有属性和业务主线存在传递依赖关系，符合第三范式
商品展示及商品管理功能
供应商管理功能
在线销售功能
问：这样的设计已经符合了范式化的要求，但是数据库处理来说，是否是高效的呢？
答：前面我们已经说过，在数据库设计时不仅要考虑到范式化，同时也要考虑到查询性能的要求！
问：编写SQL查询出每一个用户的订单总额？
答：
首先这个查询关联四张表，关于MySQL而言关联表越多性能越差，虽然说四张表并不算多，但是这样的查询可能会非常的频繁，所以如果能减少关联表的数量，能提高性能！
问：现在只在商品表中记录了价格，一旦商品发生价格变动，会产生什么样的问题呢？
答：这样会导致历史订单的价格也会发生变化，我们恰恰是不想要看到的。
假设下单用户就是商品的收货人，我们在发货前一定要查询出每个订单的下单人信息，而这些信息全部记录在用户信息表中。
问：编写SQL查询出下单用户和订单详情？
答：
结论：完全符合范式化的设计，有时并不能得到良好的SQL查询性能(即反范式化设计)。
-
需求分析及逻辑设计-反范式化设计
问：什么叫做反范式化设计？
答：反范式化是针对范式化而言的，在前面介绍了数据库设计的方式，所谓的反范式化就是为了性能和读取效率的考虑，而适而适当的对数据库设计范式的要求进行违反，而允许存在少量的数据冗余，换句话来说，办事话就是利用空间来换取时间。
图书在线销售网站数据库的反范式化改造
反范式化改造后的查询
问：编写SQL查询出每一个用户的订单总额？
答：
问：编写SQL查询出下单用户和订单详情？
答：
-
反范式化设计总结
- 不能完全按照范式化的要求进行设计
- 考虑如何使用表
-
范式化设计和反范式化设计优缺点
- 1 范式化设计的优点
- 2 范式化设计的缺点
- 1 反范式化优点
- 2 反范式化缺点
-
数据库的物理设计介绍
问：什么是数据库的物理设计？
答：根据所选择的关系型数据库的特点，对逻辑模型进行存储结构设计。
-
物理设计涉及的内容
- 定义数据库、表及字段命名规范
- 选择合适的存储引擎
- 为表中的字段选择合适的数据类型
- 建立数据库结构
-
定义数据库表、及字段命名规范
- 定义数据库、表及字段命名要遵守 可读性原则
- 定义数据库、表及字段命名要遵守 表意性原则
- 定义数据库、表及字段命名要遵守 长名原则
-
选择适合的存储引擎
-
物理设计-数据类型的选择
为表中的字段选择合适的数据类型
当一个列可以选择多种数据类型时，应该优先考虑数字类型，其次是日期或二进制类型，最后是字符型，对于相同级别的数据类型，应该优先选择占有空间小的数据类型。
问：如何选择正确的整数类型？
答：
问：如何选择正确的实数类型？
答：
-
不同数据类型在Mysql服务器上的体现
1、表结构：
2、查询表内容：select * from t_double
3、对上述数据进行汇总操作 select i,sum(d1) as a,sum(d2) as b from t_double group by i having a<>b;
结论：21.40000000..6意味着double是非精确的值，两个double汇总和直接结果是有差异的，DECIMAL是精确地实数类型，但是所占用存储空间比上述2个大——财务数据，其他可以用double和float。
如何选择VARCHAR和CHAR类型
VARCHAR的存储特点
- VARCHAR用于存储变长字符串，只占用必要的存储空间（无论长短varchar只占有必要的存储空间，如varchar(50)近存储10个字符，只占用10个字符的宽度，字符==多个字节-->【UTF-8 1个字符==3个字节】，VARCHAR是以字符为单位不是以字节为单位，如：以UTF-8为例，varchar中存储10个字符，只要定义为10即可，而不是30）
- 列的最大长度小于255，则只占用一个额外字节，用于记录字符串长度
- 列的最大长度大于255，则要占用两个额外字节，用于记录字符串的长度
-
应该如何确定VARCHAR的宽度
-
VARCHAR的实用场景
-
如何选择varchar和char类型
-
CHAR类型的适用场景
-
物理设计-如何存储日期类型
-
如何存储日期数据
-
timestamp在Mysql的时区不同的体现
1、设置时区
set time_zone='+10:00';
2、创建表
create table t(d1 datetime,d2 timestamp);
3、插入时间值
insert into t values(new(),now());
4、插入结果
5、修改当前时区后查询变化是什么呢？
结论：timestamp数据显示和时区有关。
-
datetime、timestamp是如何存储微秒值
- 进行宽度设置（alter table t modify d1 datetime(6),modify d2 timestamp(6);）
- 插入数据（insert into t values(now(),now());）
- 查询结果有图所示
-
查看timestamp自动更新特征
- drop table t;
- create table t(id int,d1 datetime,d2 timestamp not null,d3 timestamp not null);
- insert into values(1,now(),now(),now());
- 如果只插入id（insert into t(id) value(1);）
- 插入结果，仅仅datetime类型数据为空
-
Timstamp数据结果操作结论
timestamp具有自动更新的功能，但是第二个却不能就能发现，在MySql中只有第一个Timestamp类型具有自动跟新的。
-
date类型和time类型
在mysql 5.7之前的操作如上，mysql5.7 以后的版本直接使用date类型
-
存储日期时间数据注意的事项
-
物理设计——本章节总结
-
存储引擎的最好选择
-
InnoDB存储引擎的选择注意事项
-
如何为Innodb选择主键
-
数据库设计的整个过程
