数据库-三范式优化与不推荐使用外键[通俗易懂]

数据库-三范式优化与不推荐使用外键[通俗易懂]反三范式其实是基于三范式所调整的,没有冗余的数据库未必是最好的数据库,完全按照第三范式做表的设计可能会降低查询效率(涉及多表查询,多表连接JOIN,临时表创建GROUP BY),有时候为了提高运行效率

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

什么是三范式

  • 第一范式:“第一范式的数据表必须是二维数据表”,第一范式是指数据库的每一列都是不可分割的基本数据项,强调列的原子性,某一属性不能拥有几个值。比如数据库的电话号码属性里面不可以有固定电话和移动电话值。 说明:在任何一个关系数据库中,第一范式(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)和分库分表时,会省去很多麻烦

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/6289.html

(0)
上一篇 2023-04-13
下一篇 2023-04-13

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注