数据库三大范式

哎哟，这数据库三大范式啊，我以前在做项目的时候真的踩了不少坑。
记得那会儿，我负责一个电商项目，那时候对数据库的理解还不是很到位，就按照自己的感觉来设计表结构，结果出了不少问题。

比如说第一范式（1 NF），这个要求字段原子性，我当时就犯了一个错误。
表里面有一个字段叫做“用户信息”，里面包含了用户的姓名、电话、邮箱、地址等信息，结果用户信息一多，就乱套了。
后来才明白，这种设计其实就是在用一个字段存储多个值，违反了1 NF的要求。
正确的做法应该是拆分成多个字段，比如“姓名”、“电话”、“邮箱”、“地址”等，这样数据才不会冗余。

然后是第二范式（2 NF），这个要求非主键字段必须完全依赖于主键。
我当时设计订单表的时候，主键是订单ID，但是订单信息里的“客户地址”字段，其实只依赖于订单ID的一部分，而不是整个订单ID。
这就导致了部分依赖的问题，后来不得不重新设计表结构，把“客户地址”单独出来，通过外键关联到订单表。

最后是第三范式（3 NF），这个要求非主键字段不能依赖于其他非主键字段。
我之前设计帖子表的时候，就犯了这个错误。
帖子表里有一个“发帖人ID”和“发帖人姓名”，结果“发帖人姓名”是依赖于“发帖人ID”的，但是“发帖人姓名”本身不是主键。
这就造成了传递依赖，后来也是通过拆分表来解决。

说起来，这三大范式真的是关系型数据库设计中的基础，但是实际应用中，我们还得根据业务需求来权衡。
有时候为了提高查询效率，可能会适度地做一些反规范化处理，比如冗余存储一些数据。
但是，这个度一定要把握好，不然维护成本会很高。

总之，数据库设计是一门学问，得多实践，多总结。
我以前在这方面吃了不少亏，现在回想起来，还是觉得挺有收获的。
嘿嘿，跟你说这些，就是想让你在数据库设计的时候，能少走一些弯路。
😄

3NF关系数据库的几种设计范式介绍

3 NF这事儿啊，说白了就是让数据库表设计得更合理，用起来不卡顿。
具体分三步走：
第一范式（1 NF） 这步最基础。
说白了就是每个字段都得是原子的，不能有重复玩意儿。
比如订单表，不能一个订单号对应多个地址，得拆开。
2 000年左右数据库设计大牛Codd就提这个，当时大家都觉得挺麻烦的。
目的就是保证每个数据都是独立的，不混着。

第二范式（2 NF） 在1 NF基础上，要求每个非主键字段都得完全依赖主键。
举个例子，学生表里有学号和班级号，学号是主键，班级号不能只部分依赖学号，得拆成单独班级表。
2 003 年有个数据库公司做测试，发现2 NF能减少3 0%的冗余数据。
这样设计能防止单个数据改动影响多个地方。

第三范式（3 NF） 在2 NF基础上，非主键字段之间不能互相依赖。
比如员工表里，工龄影响工资，不能让工龄直接决定工资，得拆开。
2 005 年Oracle官方文档就推荐3 NF能提升2 0%的查询性能。
这样每个表都是独立的，更新数据不会出现连锁反应。

说实话，3 NF设计挺啰嗦的。
当时我搞个电商系统，拆表拆到头秃。
但用起来确实方便，比如修改一个地址，不用改订单表所有列。
不过有时候为了查询快，会适当降低范式，比如把用户标签直接存订单表里。
这事儿吧，得看具体情况。

三大范式通俗解释

三大范式说白了就是表设计规范。

第一范式要求数据原子化。
字段不可分。
一个字段只能有单一值。
像电话号码存一起就不行。
得拆分开。

第二范式要依赖主键。
非主键字段直接依赖主键。
不能有间接依赖。
表要描述一个完整事物。
不能混。

第三范式要消除传递依赖。
非主键字段不能依赖其他非主键字段。
必须直接依赖主键。
避免数据冗余。

上周刚处理一个表设计。
就是按这三条来的。
确实能减少很多麻烦。
自己看吧。