MySQL高级第十篇：数据库设计三范式与表设计原则

  • 一、范式
  • 1. 第一范式
  • 2. 第二范式
  • 3. 第三范式
  • 二、反范式化
  • 1. 概述
  • 2. 反范式化存在的问题
  • 三、数据库表设计原则（三少一多）
  • 1．数据表的个数越少越好
  • 2．数据表中的字段个数越少越好
  • 3．数据表中联合主键的字段个数越少越好
  • 4．使用主键和外键越多越好


一、范式

1. 第一范式

  • 确保数据表中每个字段的值必须具有原子性，也就是说数据表中每个字段的值为不可再次拆分的最小数据单元。

2. 第二范式

  • 第二范式要求，在满足第一范式的基础上，还要满足数据表里的每一条数据记录，都是可唯一标识的。而且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。

3. 第三范式

  • 第三范式是在第二范式的基础上，确保数据表中的每一个非主键字段都和主键字段直接相关，也就是说，要求数据表中的所有非主键字段不能依赖于其他非主键字段。
  • 通俗地讲，该规则的意思是所有非主键属性之间不能有依赖关系，必须相互独立。

总得来说，范式有助于消除数据库的数据冗余，但也可能会降低查询效率，所以在实际开发中，经常会为了性能而反范式化。

二、反范式化

1. 概述

有的时候不能简单按照规范要求设计数据表，因为有的数据看似冗余，其实对业务来说十分重要。这个时候，我们就要遵循业务优先的原则，首先满足业务需求，再尽量减少冗余。

如果数据库中的数据量比较大，系统的UV和PV访问频次比较高，则完全按照MySQL的三大范式设计数据表，读数据时会产生大量的关联查询，在一定程度上会影响数据库的读性能。

如果我们想对查询效率进行优化，反范式优化也是一种优化思路。此时，可以通过在数据表中增加冗余字段来提高数据库的读性能。

2. 反范式化存在的问题

反范式可以通过空间换时间，提升查询的效率，但是反范式也会带来一些新问题：

  • 存储空间变大了
  • 一个表中字段做了修改，另一个表中冗余的字段也需要做同步修改，否则数据不一致
  • 若采用存储过程来支持数据的更新、删除等额外操作，如果更新频繁，会非常消耗系统资源
  • 在数据量小的情况下，反范式不能体现性能的优势，可能还会让数据库的设计更加复杂

反范式使用场景建议：字段不需要经常修改，且查询的时候不可或缺。

三、数据库表设计原则（三少一多）

1．数据表的个数越少越好

  • RDBMS的核心在于对实体和联系的定义，也就是E－R图，数据表越少，证明实体和联系设计得越简洁，既方便理解又方便操作。

2．数据表中的字段个数越少越好

  • 字段个数越多，数据冗余的可能性越大。设置字段个数少的前提是各个字段相互独立，而不是某个字段的取值可以由其他字段计算出来。当然字段个数少是相对的，我们通常会在数据冗余和检索效率中进行平衡。

3．数据表中联合主键的字段个数越少越好

  • 设置主键是为了确定唯一性，当一个字段无法确定唯一性的时候，就需要采用联合主键的方式（也就是用多个字段来定义一个主键）。联合主键中的字段越多，占用的索引空间越大，不仅会加大理解难度，还会增加运行时间和索引空间，因此联合主键的字段个数越少越好。

4．使用主键和外键越多越好

  • 数据库的设计实际上就是定义各种表，以及各种字段之间的关系。这些关系越多，证明这些实体之间的冗余度越低，利用度越高。这样做的好处在于不仅保证了数据表之间的独立性，还能提升相互之间的关联使用率。

“三少一多”原则的核心就是简单可复用。
简单指的是用更少的表、更少的字段、更少的联合主键字段来完成数据表的设计。
可复用则是通过主键、外键的使用来增强数据表之间的复用率。因为一个主键可以理解是一张表的代
表。键设计得越多，证明它们之间的利用率越高。