范式与反范式

• 范式化设计
  通过满足下面提出的三条范式规则，尽可能的避免出现数据冗余
  因为数据冗余会带来，数据UPDATE更新遗漏问题（毕竟SQL是人写的~）

• 反范式化设计
  目的是，用空间换时间，通过适当的数据冗余（8张不同业务的表结构内，都存在“”联系人电话“”字段）
  这样，虽然存储的数据字段，不是用户ID,导致数据量增大，但是查询时不需要通过联查，可以提高查询效率

1.第一范式

• 第一范式：要求表中业务字段，逻辑上不可再分
  如图：错误设计，和两种正确设计

2.第二范式

• 第二范式：要求表中必须存在业务主键 (单一业务主键 或 联合业务主键)，非业务主键，必须依赖于 单一业务主键 或 全部的联合业务主键
  如图：错误设计，和正确设计

3.第三范式

• 第三范式：要求非业务主键列不能相互依赖
  如图：错误设计，和正确设计

4.反范式

• 反范式化设计数据库，是为了提高查询效率，采用空间换时间的实现思路

• 一些情况下
  比如 存在频繁查询时，可以容忍适当的冗余设计，目的是减少多表关联查询，提高效率
  例如：订单表中冗余了商品信息和用户相关信息,避免查询订单时关联用户表和商品表去查询相关信息，提高效率

• 好查不好改
  但是冗余意味着，好查不好改，修改数据时
  冗余设计造成需要同时修改多张表中的某些字段
  容易出现业务上的Update遗漏现象（毕竟SQL是人写的~）

搞 定 撒 花 ❀❀❀❀❀❀❀❀❀❀❀❀