马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？立即注册
x
数据库的三大范式是指数据库计划中用来规范化表布局的规则。其目的是淘汰数据冗余，提高数据一致性和完备性。三大范式分别是：
第一范式（1NF）—— 原子性
第一范式要求表中的每个字段都必须是原子的，即字段中的值不可再分割。换句话说，每个字段只能包含一个值，不能是一个列表或集合。
通俗案例：
假设你有一个门生信息表：
学号姓名电话号码001小明123456789, 987654321002小红234567890, 876543210 这里，小明和小红的电话号码字段包含了多个值，违反了第一范式。为了符合1NF，需要将电话号码字段拆分成独立的记录：
学号姓名电话号码001小明123456789001小明987654321002小红234567890002小红876543210 这样，每个字段都只有一个值，符合第一范式。
第二范式（2NF）—— 消除部门依赖
第二范式要求数据库中每个非主属性（字段）都完全依赖于主键，而不是仅依赖于主键的一部门。如果一个表有复合主键，必须确保每个非主属性依赖于整个复合主键，而不是只依赖于其中的一部门。
通俗案例：
假设你有一个成绩表，复合主键是 学号 和 课程号，包含如下数据：
学号课程号姓名成绩001101小明95001102小明88002101小红92 这里，“姓名”字段依赖于“学号”字段，而不是依赖于整个复合主键“学号+课程号”。为了符合第二范式，我们可以将“姓名”从表中分离出来，建立一个独立的门生表：
- 门生表：
学号姓名001小明002小红
- 成绩表：
学号课程号成绩001101950011028800210192
这样，非主键字段“姓名”就完全依赖于主键“学号”，符合第二范式。
第三范式（3NF）—— 消除传递依赖
第三范式要求表中的非主键字段不仅要直接依赖于主键，而且不能通过其他非主键字段间接依赖于主键。如果存在这种传递依赖，就需要将其分解成多个表。
通俗案例：
假设你有一个员工表，其中有员工的 部门名称 和 部门位置，数据如下：
员工编号姓名部门名称部门位置001小明技术部北京002小红销售部上海 这里，部门位置 是通过 部门名称 间接依赖于 员工编号（主键）。即：员工的 部门名称 决定了 部门位置，所以部门位置应该从这个表中提取出来，单独放在部门表中：
- 员工表：
员工编号姓名部门编号001小明D001002小红D002
- 部门表：
部门编号部门名称部门位置D001技术部北京D002销售部上海
这样，部门位置 不再通过 部门名称 间接依赖于主键，符合第三范式。
总结
- 第一范式（1NF）：确保每个字段的值是不可分割的。
- 第二范式（2NF）：确保每个非主键字段完全依赖于主键。
- 第三范式（3NF）：确保每个非主键字段不依赖于其他非主键字段（即消除传递依赖）。
通过这些规范化的过程，可以让数据库布局更加合理，淘汰冗余数据，制止数据不一致的环境发生。
高并发系统中，三大范式的缺点是啥？
在高并发系统中，三大范式的计划虽然可以包管数据一致性和淘汰冗余，但它们也有一些缺点，尤其是在处置惩罚大量并发请求时。这些缺点重要表现在性能、复杂性和可扩展性方面。以下是每个范式的缺点及其对高并发系统的影响：
第一范式（1NF）缺点
缺点：1NF要求每个字段都是原子的，即每个字段只能存储一个值。虽然这是数据一致性的根本要求，但在高并发系统中，这种要求可能导致频仍的表拆分和数据更新操作，增加了数据库的负担。
影响：
- 由于对数据的强束缚，可能导致频仍的查询操作需要访问更多的表或记录，从而增加了数据库的查询本钱。
- 太过拆分可能导致多个查询请求必须归并数据，增加了系统的复杂性和查询相应时间。
第二范式（2NF）缺点
缺点：2NF要求消除部门依赖，确保每个非主键字段完全依赖于主键。在复杂的业务场景中，消除部门依赖可能会导致过多的表拆分。
影响：
- 在高并发的系统中，拆分表后，涉及多个表的联接查询会变得非常复杂，增加了数据库的负担，可能导致查询性能降落。
- 由于每个非主键字段需要完全依赖于主键，可能导致数据模子过于复杂，查询时需要访问更多的表，影响系统的相应速率。
第三范式（3NF）缺点
缺点：3NF消除了传递依赖，使得全部非主键字段都不依赖于其他非主键字段。这个原则可能导致数据库太过规范化，使得数据存储非常分散。
影响：
- 查询效率低：在高并发系统中，过多的表拆分和复杂的表之间的关系会导致频仍的联接（JOIN）操作，特别是在需要获取多表数据时，可能会明显增加查询的时间。
- 事务和一致性问题：频仍的表拆分和数据分布可能会引入更多的事务操作，导致锁的竞争和性能瓶颈。在高并发场景下，太过的表分解可能导致更频仍的锁竞争和事务辩说。
- 更高的写入本钱：每次更新或插入数据时，可能需要更新多个表。这会导致更高的写入延迟，尤其是在事务涉及多个表的环境下。对于高并发写入的系统，这可能会成为瓶颈。
高并发环境下的折中与办理方案
在高并发的环境下，严格遵照三大范式可能会导致性能瓶颈，尤其是在查询和写入操作上。为了提高系统的性能和可扩展性，通常会接纳以下计谋：
- 去规范化（Denormalization）：
- 去规范化是指在数据库中故意增加冗余数据，淘汰表的拆分，以降低复杂查询的本钱。
- 虽然去规范化会引入肯定的数据冗余，但它能够明显提升查询性能，尤其是在高并发读操作中。
- 缓存：
- 高并发系统中，缓存是提高性能的常用方案。通过使用缓存（如Redis、Memcached）来缓存频仍查询的数据，可以淘汰数据库的查询负载，提升相应速率。
- 分库分表：
- 对于大量数据，可以使用分库分表技术将数据分散存储，从而提高查询效率，并淘汰单一数据库的压力。
- CQRS（命令查询分离）：
- 将读和写操作分离，分别采用不同的优化计谋。比方，写操作使用事务和高一致性包管，而读操作则采用缓存、去规范化等方式来提升性能。
- 数据库索引：
- 对常用的查询字段添加索引，可以明显提高查询效率，但需要注意索引会增加写操作的本钱。
总结
- 第一范式（1NF）：可能导致频仍的表拆分，增加查询的复杂性。
- 第二范式（2NF）：可能导致表的太过拆分，查询性能降落。
- 第三范式（3NF）：虽然消除了数据冗余，但可能会导致查询性能降落，增加了数据库复杂度，特别是在高并发写入的环境下。
因此，在高并发系统中，往往需要在规范化和性能之间找到平衡点，采用去规范化、缓存、分库分表等技术来优化性能。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
