数据库建表范式与反范式

「爱情、让人受尽委屈。」 2022-01-15 20:53 271阅读 0赞

**范式**：为了建立冗余较小，结构合理的数据库，设计数据库需要遵循的规则。

*  第一范式（确保每列保持原子性）

> 第一范式是最基本的范式，如果数据库中所有字段都是不可分解的原子值，说明满足第一范式。第一范式的合理遵循需要根据系统的实际需求来定。比如数据库经常用到的“地址”属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统需要访问属性中的“城市”部分，那么就需要将“地址”这个属性拆分为省、市、具体地址等多个部分进行存储。

*  第二范式（确保表中的每列都与主键相关）

> 首先满足第一范式，另外还需包含两部分内容：一：表必须有一个主键；二：没有包含在主键的列必须完全依赖于主键，而不能只依赖于主键的一部分。也就是说一个数据表中一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

如：订单信息表

上述表中，以订单编号和商品编号作为联合主键，则这张表中商品名称、单位、价格等信息不与主键相关，只与编号相关，违反了第二范式 应该对订单信息表进行拆分，商品信息单独一张表，订单项目一张表，如下所示

订单信息表

订单详情表

商品信息表

*  第三范式（确保每列都和主键列直接相关，而不是间接相关）

> 概念说起来比较绕口，直接举例子说明：存在一个部门信息表，每个部门都有dep\_id,dep\_name,dep\_des等信息。那么在员工表中列出dep\_id后，dep\_name,dep\_des等信息就不能再加入员工信息表中。如果不存在部门信息表，则根据第三范式也应该构建，否则会有大量的数据冗余。

**范式的优点**：范式避免了数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦； **范式的缺点**：范式往往需要进行多表连接，当数据量很大时，效率比较低

有范式，自然就有反范式，不满足范式的模型，就是反范式模型。当业务涉及的表非常多时，经常会有多表发生关系，并且对表的操作要时间上尽量的快，这时可以考虑使用反范式。但是反范式，对于更新数据来说，比较麻烦，容易出错。而且反范式会有很多的重复数据，或占用较多的内存，查询时可能会较多的使用group by或distinct等耗时耗性能的关键字。

终于把范式整理完了，开发了这么多年，范式的概念还是在大学中学到，但那时理解不深刻，早已把概念忘的一干二净。实际项目中，做db设计并没有强调说一定要遵循范式，都是根据业务混合使用不同的模式，将各种模式的优点最大的发挥

转载于:https://my.oschina.net/wuyiyi/blog/3042902