表结构设计优化

第一范式（1NF）

• 字段具有原子性，即数据库的每一个字段都是不可分割的原子数据项，不能是集合、数组、记录等非原子数据项

• 当实体中的某个属性有多个值时，必须拆分为不同的属性

例子：

如图，student表不符合第一范式，因为地址字段不是原子性的，还可以继续拆分成省、市

并且，如果这样设计，假设以后有按照省、市进行统计或分组的需求，这样的表设计无法实现

可以改成以下这样，就满足第一范式（1NF）了

第二范式（2NF）

• 满足1NF的基础上，要求每一行数据具有唯一性，并且非主键字段完全依赖主键字段

例子：

如果student表能够做到每一行数据具有唯一性，但是这张表里面的非主键字段并不完全完全依赖主键字段

比如，课程学分字段credit(课程学分)字段只依赖classname(课程)，而不依赖no(学号)字段，也就是说credit(课程学分)字段只是部分依赖主键no(学号)字段。不符合第二范式（2NF）

可以改成以下这样，就满足第二范式（2NF）了

拆分成两张表，credit(课程学分)字段依赖classname(课程)

第三范式（3NF）

• 满足2NF的基础上，不能存在传递依赖

例子：

student表设计如下，school_addr(学校地址)、school_phone(学校电话)字段都依赖school(学校)字段，school(学校)字段又依赖了主键id字段。也就是说school_addr(学校地址)、school_phone(学校电话)字段并不直接依赖主键id字段，而是通过school(学校)字段，传递依赖了主键id字段，这种情况下就不符合第三范式（3NF）了

可以改成以下这样，就满足第三范式（3NF）了

总结

三范式带来的好处，就是防止了冗余，一般来说，在设计表时需要遵循三范式。但是实际项目中，一些场景下也需要做一些反模式设计。

反模式设计

• 放弃遵循三范式，适当增加冗余，从而提升查询效率

例子：

假设如下这两张表的数据都非常多，并且在查询学生信息时，总是要查询school_addr(学校地址)这个字段

那么就可以把school_addr(学校地址)字段冗余到student表中。这样在查询学校信息时，就不需要两张表联合查询，直接单表查询即可，从而提升性能

表设计原则

• 字段少而精，建议20个以内（经验之谈），超过可以拆分
  • 把常用的字段放到一起
  • 把不常用的字段独立出去
  • 打字段（TEXT/BLOB/CLOB等）独立出去
• 尽量使用小型字段
  • 一些场景下，用数字替代字符串
    • 比如，存储ip字段，可以用int类型代替varchar类型，可以节省空间，也可以提升性能
• 避免使用允许为NULL的字段
  • 官方也推荐字段设置为非空
  • 允许为NULL的字段很难查询优化
  • 允许为NULL的字段的索引需要额外的空间
• 合理平衡范式和冗余
• 如果数据量非常大，考虑分库分表