教学管理系统的教学据库计数据库设计，核心就一句话：别把学生、管理课程、系统教师、数的设成绩全塞一张表里。教学据库计我见过一个教务系统，管理所有信息挤在一张叫“教务总表”的系统宽表里，字段超过80个。数的设选课高峰期，教学据库计一个简单的管理查成绩操作要等十几秒，因为每次查询都在扫全表。系统后来重构，数的设拆成七张表，教学据库计同样的管理硬件，响应时间降到200毫秒以内。系统这就是数据库设计的第一道分水岭——你愿不愿意花时间做范式分解。

先说学生表。学号做主键，这个没什么争议。但很多设计者会忽略一个细节：学号本身可能变。比如专升本的学生，学号前缀会调整。如果外键全部硬编码学号，迁移时就是灾难。我的做法是加一个自增的student_id作为内部主键，学号只作为业务唯一键加唯一索引。这样即使学号规则改了，关联关系纹丝不动。学生表里还必须有入学年份、专业ID、班级ID、状态（在读/休学/毕业）。状态字段用tinyint而不是varchar，省空间也省索引。

课程表的设计有个坑：课程和课程班是两回事。“数据结构”是一门课程，但每学期可能开三个班，每个班有不同教师、不同时间。所以至少两张表——course存课程代码、名称、学分、总学时；course_section存学期、教师ID、上课时间、教室、容量。选课记录挂在course_section上，不是挂在course上。我见过把选课直接关联到课程表的，结果同一门课不同班的成绩混在一起，教务老师手动分班分了三天。

成绩表最容易被轻视。很多系统只存一个最终分数，但实际教学管理需要过程性数据——平时成绩、期中、期末、补考、重修。一张score表，字段包括选课记录ID、成绩类型、分数、录入时间、录入教师。成绩类型用枚举或字典表。这里有个性能考量：成绩查询频率极高，尤其是学生端。我在选课记录ID和成绩类型上建了联合索引，覆盖大部分查询场景。另外，分数用decimal(5,2)而不是float，避免浮点误差导致59.999被显示成60。

教师表相对简单，但要注意教师可能同时是管理员、班主任。角色权限不要塞进教师表，单独建user_role和role_permission。教师ID和用户ID可以合一，也可以分开。我倾向于分开，因为有些外聘教师只录成绩，不登录系统。

选课记录表是枢纽。它连接学生和课程班，还要记录选课时间、状态（已选/退选/待审核）。这里有个并发问题：多个学生同时抢最后一个名额。数据库层面用唯一约束防止重复选课，用乐观锁或行锁控制容量。我试过在应用层用Redis预扣减，数据库只做最终一致性，效果不错，但增加了复杂度。小规模系统直接SELECT ... FOR UPDATE就够了。

最后提一个容易忽略的点：学期表。很多系统把学期硬编码成字符串“2024-2025-1”，导致跨年查询要字符串匹配。建一张semester表，存学期ID、开始日期、结束日期、是否当前学期。所有涉及学期的表都存学期ID。这样查“最近三个学期”就是简单的ID排序，不用解析字符串。

数据库设计没有银弹。范式分解能减少冗余，但过度分解会让查询变成五表JOIN。我的经验是：核心业务表保持第三范式，报表和统计需求用视图或物化视图解决。别为了“优雅”牺牲教务老师导出Excel的速度。