MYSQL（4）——范式设计和反范式设计
name-age列具有两个属性，一个name,一个 age不符合第一范式，把它拆分成两列
有两张表：订单表，产品表
一个订单有多个产品，所以订单的主键为【订单ID】和【产品ID】组成的联合主键，这样2个组件不符合第二范式，而且产品ID和订单ID没有强关联，故，把订单表进行拆分为订单表与订单与商品的中间表
其中
客户编号 和订单编号管理 关联
客户姓名 和订单编号管理 关联
客户编号 和 客户姓名 关联
如果客户编号发生改变，用户姓名也会改变，这样不符合第三大范式，应该把客户姓名这一列删除
【参考：三大范式概念解读
http://www.360doc.com/content/12/0712/20/5287961_223855037.shtml】
只有一个业务主键，一定是符合第二范式
没有属性和业务主键存在传递依赖的关系，符合第三范式
一个商品可以属于多个分类，故，商品名称和分类应该是组合主键，会有大量冗余，不符合第二范式。应该把分类信息单独存放；
另外再建立一个中间表把分类信息和商品信息进行关联；
最终建立三张表
符合三大范式，不需要修改，但假如增加新的一列【银行支行】，这样随着银行账户的变化，银行支行也会变化，不符合第三大范式
有多个业务主键，不符合第二范式
订单商品单价。订单数量，订单金额 存在传递依赖关系，不符合第三范式
拆分的结果如下
这时候，【订单商品分类】与【订单商品名】有依赖关联，故合并如下
编写SQL查询出每一个用户的订单总金额（用户名，订单总金额）
编写SQL查询出下单用户和订单详情（订单编号，用户名，手机号，商品名称，商品数量，商品价格）
商品信息和分类信息经常一起查询，所以把分类信息也放到商品表里面，冗余存放
在线销售功能反范式
下面是在线手写功能的范式设计
首先来看订单表
1.查询订单信息要关联查询到用户表，但用户表的电话是可能改变的，而且查询订单的时候经常查询到用户的电话
2.查询订单经常会查询到订单金额，所以把订单金额也冗余进来
新设计的订单表如下
再来看订单关联表
1.和商品信息反范式设计一样，查询订单的时候经常查询商品分类，所以把商品分类和订单名冗余进来
2.商品的单价可能会编号，如果关联查询查询只能查询到最新的商品价格，而查询不到下订单时候的价格，并且商品单价经常会查询。 所以把订单单价也冗余进来
新设计的商品关联表如下
查询练习
编写SQL查询出每一个用户的订单总金额
物理设计
命名规范
数据库、表、字段的命名要遵守可读性原则
使用大小写来格式化的库对象名字以获得良好的可读性
例如：使用custAddress而不是custaddress来提高可读性。
数据库、表、字段的命名要遵守表意性原则
对象的名字应该能够描述它所表示的对象
例如：
对于表，表的名称应该能够体现表中存储的数据内容；对于存储过程
存储过程应该能够体现存储过程的功能。
数据库、表、字段的命名要遵守长名原则
尽可能少使用或者不使用缩写
存储引擎选择
数据类型选择
当一个列可以选择多种数据类型时
优先考虑数字类型
其次是日期、时间类型
最后是字符类型
对于相同级别的数据类型，应该优先选择占用空间小的数据类型
浮点类型
日期类型
面试经常问道 timestamp 类型 与 datetime区别
datetime类型在5.6中字段长度是5个字节
datetime类型在5.5中字段长度是8个字节