网站开发后台数据库怎么搞各大门户网站

背景

• 数据库的范式（Normal Form）是一组规则，用于设计数据库表结构以 减少数据冗余 和 提高数据完整性
• 范式的概念最早由埃德加·科德（Edgar F. Codd）提出，他是关系型数据库之父。
• 范式是一系列的 设计规则

  从第一范式到更高的范式（如第二范式2NF、第三范式3NF、Boyce-Codd范式（BCNF）、第四范式4NF、第五范式NF等）。
  每个层次都建立在前一个层次的基础上，进一步消除数据冗余和依赖关系。

• 范式虽然分为多个级别，但最常用的是前三个范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）

范式介绍

接下来我们会用一个学生信息存储表来举例来了解一下三大范式的规则。
这张表需存储：学生学号、学生姓名、考试分数、分数等级、考试科目、手机号码 信息。

• 初始表格 【表_0】 如下：
  

第一范式：属性不可再分

First Normal Form，但是通常我们用“1NF”来表示

• 定义

  如果一个表符合第一范式，么这个表中的每个字段都必须包含单一值，而不能是数组或者集合。
  即表中的每个属性都是原子的，不可再分割

• 特点
  • 所有列的值都不可再分割，且没有重复的列
  • 每行都是唯一的
• 示例解析

  【表_0】中，score列存储了分数和分数等级两个数据。

• 缺点：
  • （1）如果需要求学生的总分时，还需要对数据进行切割，损耗了性能
  • （2）如果需要等级A的学生的总数时，只能进行模糊查询，损耗率性能
  • （3）不能按照分数或者分数等级进行分组排序
• 优化:
  • 将分数和等级拆分成 score 和 score_level 两个字段。优化结果如下【表_1】
    

第二范式

Second Normal Form，但是通常我们用“2NF”来表示

• 定义

  在满足第一范式的基础上，消除部分依赖。
  即，每个非主属性必须依赖于整个主键，而不能仅依赖于部分主键

• 特点

  1、第二范式一定是第一范式，第一范式是基础
  2、非主属性不能依赖部分属性（没懂不要急，马上就要解释了）

• 示例解释
  • 【表_1】中，学号(sno)+学科(subject)可以唯一的确定一列。所以【sno+subject】为主键。
    但是学生姓名(sname) 和 电话号码(phone)确是只依赖于sno存在的。
• 缺点：
  • 数据产生了大量的冗余数据，会增加查询的耗时，也会增加数据一致性的维护成本

    假如学生有十门考试成绩，那么就会存储十份电话号码。
    如果某一个数据出现了不一致的情况，就会不确定正确的数据是哪个了

• 优化：我们对表进行拆分成【个人信息表】 和【考试成绩表】
  
  

第三范式

Thrid Normal Form，但是通常我们用“3NF”来表示

• 定义

  在满足第二范式的基础上，消除传递依赖，即非主属性不能依赖于其他非主属性

• 特点

  所有非主属性都直接依赖于主键，而不能依赖于其他非主属性

• 示例解释

  在上边的学生信息表中，score_level的取值依赖于score的值。
  如果 score >= 90，那么 score_level=“A”；
  如果71<= score <= 89，那么 score_level=“B”；
  如果 score <= 70，那么 score_level=“C”；

• 优化：将score_level拆分出来成一个等级表，且该等级表不会改变
  （这里数字太多，我们就只写上边出现的数字吧）
  
  

  这里举例用分数不太恰当，感受不出第三范式的简洁来。
  我们可以这么理解，在公司中的员工考核，评价A+\A\A-，等级均为A；评价B+\B\B-，等级均为B；
  评价C+\C\C-，等级均为C；
  然后我们在等级表中,就只需要存储9条信息就可以了。对比与将考核等级仅满足第二范式，这样可以更清楚的了解等级的划分标准。

注意事项

• 虽然三大范式是数据库的基本原则，但是在实际情况中也需要根据实际项目情况进行取舍，不要过度追求规范化

  过度规范化可能会导致数据表数量增多、关系变得更加复杂，从而增加查询和维护的难度

• 如果是大数据量，如表里数据有2000w+，查询时需要关联多张表才能取到完整的数据，造成性能瓶颈。这时候我们可以在表中适当的冗余（用空间换时间~）
• 所以，在设计数据库时需要根据实际需求进行灵活调整。

为什么不遵循后续的范式

• 在实际应用中，数据库的设计并不需要达到BCNF级别，更不用说4NF\5NF。
  • 1、随着范式的提高，数据库的设计变得更复杂也更难维护
  • 2、高范式可能导致更多的连表查询，影响数据库的性能
  • 3、虽然存在更多范式，但实际中1NF、2NF、3NF常被提及和使用
    （虽然我们大学也学高数，但实际生活中买东西，我们并不需要去求导~😏😏😏）

数据库范式在实际应用中会遇到哪些挑战？

• 1、设计复杂度高

  高范式的设计意味着更多的表和更复杂的表关系，增加了数据库的设计和理解难度

• 2、性能下降

  高范式下查询因为要多表连接，会导效率下降，尤其在大数据和高并发访问的场景下尤为明显。

• 3、存储空间更大

  因为数据不断拆分为多个表，会占用更多的存储空间

• 4、数据一致性的维护

  在更改一个数据时，需要确保相关表中的数据都得更新

• 5、插入、更新、删除异常

  在非常严格范式的要求下，如果要增加一条数据，需要先检查多个表。在更新或者删除时，也可能因为依赖关系而更新或者删除不成功

• 6、数据冗余

  有时为了提升效率而故意引入冗余数据