当前位置:Gxlcms > 数据库问题 > 数据库-三范式优化与不推荐使用外键

数据库-三范式优化与不推荐使用外键

时间:2021-07-01 10:21:17 帮助过:12人阅读

什么是三范式

  • 第一范式:“第一范式的数据表必须是二维数据表”,第一范式是指数据库的每一列都是不可分割的基本数据项,强调列的原子性,某一属性不能拥有几个值。比如数据库的电话号码属性里面不可以有固定电话和移动电话值。 说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。

  • 第二范式:建立在第一范式的基础上,即满足第二范式一定满足第一范式,第二范式要求数据表每一个实例或者行必须被唯一标识。除满足第一范式外还有两个条件,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。每一行的数据只能与其中一列相关,即一行数据只做一件事。只要数据列中出现数据重复,就要把表拆分开来。

  • 第三范式:满足第二范式,且每一个非主属性都不传递依赖于该范式的候选键,则称为第三范式,即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。

三范式优化

  • 主要是满足第三范式,即不产生数据冗余、插入异常、删除异常、依赖传递等。

拆分表,一张有依赖传递的表,如(blog、blog_class、blog_class_description),拆分成 blog(主表)、blog_class+blog_class_description(依赖关系表)、blog+blog_class(关联关系表)

反三范式优化

  • 反三范式其实是基于三范式所调整的,没有冗余的数据库未必是最好的数据库,完全按照第三范式做表的设计可能会降低查询效率(涉及多表查询,多表连接JOIN,临时表创建GROUP BY),有时候为了提高运行效率,就必须降低范式的标准,适量保留冗余数据。
  • 在概念数据模型设计时遵守第三范式,降低范式标准的工作放在物理数据模型时考虑。
  • 适当的合并一些表的字段(减少表的数量),产生一些字段冗余,降低了查询时的关联,有时候可以提高查询效率。
  • 因为在数据库操作中,DQL的比例是要远大于DML的
  • 反三范式优化一定要适度,并且是在原本满足但三范式的基础上做调整的。

为什么不推荐使用外键

外键的优点

1、数据一致性

由数据库自身保证数据一致性、完整性会更可靠。

2、ER图可靠性、可读性

有主外键的数据库可以增加数据库可读性

外键的缺点

1、级联

在阿里巴巴开发手册中,就强制要求不允许使用外键,所有的外键概念必须在应用层解决,因为每次级联DML操作时,都要级联操作相关的外键表,在高并发场景会导致性能瓶颈。

2、数据库压力增加

外键等于将数据库一致性实现,全部交给数据库服务器完成,有了外键,当进行DML操作后,需要出发相关的操作去检查,应用程序执行的判断转移到了数据库上,增加资源消耗,数据库性能开销变大。

3、死锁

每次修改都要去另外的表检查数据,获取额外的锁。高并发大流量事务场景,使用外键可能容易造成死锁。

4、开发、维护不方便

有外键在需要手工维护数据时,都需要考虑级联问题,数据库平台迁移(如MySQL迁移到DB2)和分库分表时,会省去很多麻烦

数据库-三范式优化与不推荐使用外键

标签:表连接   允许   多表   平台   基础   执行   电话号码   固定   流量   

人气教程排行