数据库监控与调优【十七】—— 表结构设计优化

表结构设计优化

第一范式(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的字段的索引需要额外的空间
  • 合理平衡范式和冗余
  • 如果数据量非常大,考虑分库分表
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值