ID：1234567890 把关系型数据库想象成一栋大楼，“三大范式”就是它的地基和承重结构。这些标准规定了表结构必须满足的最低要求，目的就是为了让数据存放得稳固，不出现乱七八糟的情况。 第一范式要求每个字段里只能存一个独立的值，也就是“一列一个值”。别在一个格子里把电话和住址都写在一起。比如“联系方式”字段里写了13800000000和010-88888888，那就是违规的。最好把手机号和家庭电话分开来放。要是有人联系不止一次，那就得弄张专门的联系方式表。 第二范式主要盯着那些用了组合主键的表。非主键字段不能只依赖一半的主键信息，要完全依赖于整个主键。就像选课表里如果只有“学生ID”和“课程ID”做主键，“学生姓名”只跟学生ID有关，“课程名称”只跟课程ID有关。这就形成了部分依赖，导致数据重复存储很多次。解决办法就是把名字和课程分开存到各自的表里，选课表只记录成绩就行。 第三范式要把非主键字段之间的间接依赖给切断。假如员工表里有员工ID、姓名、部门ID和部门名称，“部门名称”实际上是通过“部门ID”才跟“员工ID”扯上关系的。这就是传递依赖。如果部门改名字了，就得把所有员工的部门名称都改一遍。为了避免这种麻烦，最好把部门ID和名称分开放到部门表里。 虽然范式的规矩很严，但为了让系统跑得快点，有时候还是得故意打破一下规矩。像在订单表里直接把商品名称和单价存下来，虽然这会导致数据冗余（也就是不符合第三范式），但这样就不用每次都去关联商品表查数据了。这种做法能节省时间，还能保留历史价格不变的真实性。 总之，“三大范式”是设计数据库的基准线。好的设计师懂得先把结构理通顺了，再根据业务需求适当地把冗余加进去做优化。