MySQL——业务设计

逻辑设计

范式设计

范式概述

第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求，否则，将有很多基本操作在这样的关系模式中实现不了。

第二范式：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。

第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF。

第一范式

1、数据库表中的所有字段都只具有单一属性。
2、单一属性的列是由基本数据类型所构成的。
3、设计出来的表都是简单的二维表。

例如：

name-age列具有两个属性，一个name，一个 age不符合第一范式，把它拆分成两列。

第二范式

要求表中只具有一个业务主键，也就是说符合第二范式的表不能存在非主键列只对部分主键的依赖关系。
例如：有两张表：订单表，产品表


一个订单有多个产品，所以订单的主键为【订单ID】和【产品ID】组成的联合主键，这样2个主键不符合第二范式，而且产品ID和订单ID没有强关联，故，把订单表进行拆分为订单表与订单与商品的中间表。

第三范式

指每一个非主属性既不部分依赖于也不传递依赖于业务主键，也就是在第二范式的基础上消除了非主键对主键的传递依赖。
例如：

其中
客户编号 和订单编号管理 关联
客户姓名 和订单编号管理 关联
客户编号 和 客户姓名 关联

如果客户编号发生改变，用户姓名也会改变，这样不符合第三大范式，应该把客户姓名这一列删除

反范式设计

范式设计中存在的问题
大量的表关联非常影响查询的性能，完全符合范式化的设计有时并不能得到良好得SQL查询性能。

什么叫反范式化设计

所谓得反范式化就是为了性能和读取效率得考虑而适当得对数据库设计范式得要求进行违反。允许存在少量得冗余，换句话来说反范式化就是使用空间来换取时间。

总结

不能完全按照范式得要求进行设计，根据业务考虑以后如何使用表。

范式化设计优缺点

优点：
可以尽量得减少数据冗余
范式化的更新操作比反范式化更快
范式化的表通常比反范式化的表更小

缺点：
对于查询需要对多个表进行关联
更难进行索引优化

反范式化设计优缺点

优点：
可以减少表的关联
可以更好的进行索引优化

缺点：
存在数据冗余及数据维护异常
对数据的修改需要更多的成本

物理设计

命名规范

数据库、表、字段的命名要遵守可读性原则。
数据库、表、字段的命名要遵守表意性原则。
数据库、表、字段的命名要遵守长名原则。

存储引擎选择

数据类型选择

当一个列可以选择多种数据类型时：
1）优先考虑数字类型
2）其次是日期、时间类型
3）最后是字符类型
4）对于相同级别的数据类型，应该优先选择占用空间小的数据类型

浮点类型

日期类型

面试经常问道 timestamp 类型 与 datetime区别
datetime类型在5.6中字段长度是5个字节
datetime类型在5.5中字段长度是8个字节
字段长度所占的字节数不同，timestamp和时区有关，而datetime无关。