4 三范式评价
优点
- 范式化的更新通常比反范式快
- 当数据较好的范式化后，很少或者没有冗余数据
- 范式化的数据比较小，放在内存中操作较快
缺点
- 通常需要进行关联
毕竟阿里规范提到 
5 反范式（空间换时间）
反范式的过程就是通过适当的数据冗余来提高查询性能，但冗余数据会牺牲数据一致性。
优点
- 所有的数据都在同一张表中，可以减少表关联
- 更好进行索引优化
缺点
- 存在大量冗余数据
- 数据维护成本更高（删除异常，插入异常，更新异常）
在企业中很好能做到严格意义上的范式成者反范式，一般需混合使用。
适当的数据冗余
- 被频繁引用且只能通过Join 2张(或者更多)大表的方式才能得到的小独立字段
- 这样的场景由于每次Join仅仅只是为了取得某个小字段的值，Join到的记录又大，会造成大量不必要的lO,完全可以通过空间换取时间的方式来优化。
不过，冗余的同时需要确保数据的一致性不会遭到破坏，确保更新的同时冗余字段也被更新。
6 综合案例
在一个网站实例中， 这个网站允许用户发送消息，井且一些用户是付费用户。现在想查看付费用户最近的10条信息。在user表 和message表中都存储用户类型(account type)，而不用完全的反范式化。这避免了完全反范式化的插入和删除问题，因为即使没有消息的时候也不会丢失用户信息。这样也不会把user_message表搞得太大，有助高效获取数据
另一个从父表冗余些数据到子表的理由是排序的需要
缓存衍生值也是有用的。如果需要显示每个用户发了多少消息(类似论坛)，可以每次执行一个昂贵的子查询来计算并显示它；也可以在user表中建个num_messages列，每当用户发新消息时更新这个值。
范式设计
- 用户表
用户ID、姓名、电话、地址、邮箱 - 订单表
订单ID、用户ID、下单时间、支付类型、订单状态 - 订单商品表
订单ID、商品 ID、商品价格 - 商品表
商品ID、名称、描述、过期时间
SELECT b.用户名, b.电话, b.地址, a.订单ID, SUM(c.商品价价*C.商品数量) as 订单价格 // 上面这就需要三张表的关联了,可能效率就很低了 FROM‘订单表` a JOIN‘用户表’b ON a用户ID=b.用户ID JOIN `订单商品表` C ON c.订单ID= b.订单ID GROUP BY b.用户名，b.电话b.地址,a.订单ID
反范式设计
- 用户表
用户ID、姓名、电话、地址、邮箱 - 订单表
订单ID、用户ID、下单时间、支付类型、订单状态、订单价格、用户名、电话、地址 - 订单商品表
订单ID、商品 ID、商品数量、商品价格 - 商品表
商品ID、名称、描述、过期时间
SELECT a.用户名,a.电话.a.地址 ,a.订单ID ,a.订单价格 FROM `订单表` a
把用户表的地址加到了订单表，这样查询地址时，就不需要把用户表和订单表关联
参考
