简介这份资源是面向高校计算机相关专业学生的数据库课程设计实践案例围绕教务管理系统展开采用MySQL与Java技术栈帮助读者理解从需求分析、数据库设计到系统实现与测试的完整开发流程适合正在学习数据库原理与应用、Java编程等课程、需要完成课程设计或提升动手能力的学生参考使用。压缩包共28个文件约4.45MB包含9个java源文件与9个class编译文件、properties配置、jar依赖包、sql建库脚本及工程配置文件等覆盖源码、数据库脚本与工程结构便于直接导入运行和二次修改。目前已有2649人学习下载具备一定的参考热度。读者可从中获得教务管理场景下的数据库表结构设计思路、Java实现代码与工程组织方式并据此完成个性化改造与功能扩展为后续数据库应用开发打下实践基础。1. 教务管理系统课程设计从选课冲突到成绩归档的完整数据库方案每年选课季教务系统最怕的不是流量高峰而是同一门课被两个班同时抢、一个学生选了两门时间重叠的课、成绩录到一半发现学号对不上。数据库课程设计如果只做增删改查答辩时很难讲出深度真正能撑住场面的是把选课冲突检测、成绩归档、权限隔离这些教务场景里的硬骨头啃下来。这套基于 MySQL 与 Java 的教务管理系统面向课程设计、毕设开题和需要交付完整数据库方案的读者覆盖学生、教师、教务管理员三类角色核心表结构、事务边界和冲突校验逻辑都按可落地的标准设计不是玩具级 Demo。2. 需求与数据模型三类角色、六张核心表怎么定2.1 先定业务边界再画 E-R 图教务管理系统的需求看起来杂但落到数据库层面真正需要建模的实体并不多。我一般先把业务边界收在三件事上学生选课与退课、教师录入成绩、教务管理员维护课程与班级。超出这三件事的功能比如排课算法、教室调度课程设计阶段直接砍掉否则表结构会膨胀到无法在答辩前讲清楚。角色与权限的划分决定了后续表设计的粒度。学生只能看到自己的选课记录和成绩教师只能操作自己任教课程的成绩教务管理员拥有课程、班级、学生信息的维护权限。这个约束不是靠前端隐藏按钮实现的而是要在数据库层通过外键关联和查询条件双重保证。很多同学翻车就翻在这里前端把按钮藏了后端接口却裸奔答辩时老师随便构造一个请求就能改别人成绩。E-R 图的核心关系可以这样梳理学生与课程是多对多通过选课表关联教师与课程是一对多一门课由一个教师主讲班级与学生是一对多一个班包含多名学生。选课表是整张图的枢纽它同时承载了学生、课程、学期、成绩四个维度的信息也是后面冲突检测和成绩归档的主战场。2.2 六张核心表的结构与字段取舍表结构设计最忌讳一上来就堆字段。我的习惯是先确定每张表的“主键 业务唯一键 状态字段”三件套再往里填业务属性。下面这套结构经过课程设计场景验证字段数量控制在可讲清楚的范围内。-- 学生表学号作为业务唯一键自增 id 仅作内部关联 CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, stu_no VARCHAR(20) NOT NULL UNIQUE COMMENT 学号业务唯一标识, name VARCHAR(50) NOT NULL, class_id BIGINT NOT NULL COMMENT 所属班级, password VARCHAR(64) NOT NULL COMMENT 存储加盐哈希不存明文, status TINYINT DEFAULT 1 COMMENT 1在读 0离校, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_class (class_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 课程表课程号唯一容量字段用于选课人数上限校验 CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(100) NOT NULL, teacher_id BIGINT NOT NULL, credit DECIMAL(3,1) NOT NULL COMMENT 学分支持0.5, capacity INT NOT NULL DEFAULT 60 COMMENT 选课容量上限, semester VARCHAR(20) NOT NULL COMMENT 如2024-2025-1, KEY idx_teacher (teacher_id), KEY idx_semester (semester) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 选课表学生课程学期唯一防止重复选课 CREATE TABLE enrollment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, semester VARCHAR(20) NOT NULL, score DECIMAL(5,2) DEFAULT NULL COMMENT NULL表示未录入, status TINYINT DEFAULT 1 COMMENT 1已选 2已退, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_stu_course_sem (student_id, course_id, semester), KEY idx_course (course_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;教师表、班级表结构相对简单这里不展开。重点说三个设计取舍。第一选课表的唯一键包含学期字段因为同一门课可能在不同学期重复开设学生跨学期选同一门课是合法的但同一学期内重复选必须被数据库拦住。第二成绩字段允许为 NULL用 NULL 表示“未录入”而不是用 0 分这个区别在统计及格率时非常关键0 分和未录入是两回事。第三所有表统一用 utf8mb4避免学生姓名里的生僻字变成问号这是血泪经验答辩现场演示时名字乱码很尴尬。提示选课表的唯一键是防重复选课的最后一道防线应用层的“先查再插”在高并发下会失效必须靠数据库唯一约束兜底。2.3 索引不是越多越好按查询路径来建课程设计里常见的误区是给每个字段都加索引结果插入变慢、答辩时也说不清为什么建。正确的做法是按实际查询路径反推。教务系统的高频查询无非四类按学号查学生、按学期查课程、按学生查选课记录、按课程查选课名单。对应的索引在上面的建表语句里已经埋好student 表的 stu_no 唯一索引、course 表的 semester 索引、enrollment 表的 uk_stu_course_sem 联合唯一索引和 idx_course 索引。联合唯一索引 uk_stu_course_sem 的顺序有讲究。把 student_id 放在最前面是因为“查某个学生的所有选课”是最频繁的操作这个索引可以直接覆盖该查询。如果反过来把 course_id 放前面查学生选课就用不上这个索引只能走 idx_course 再过滤效率差一截。这类细节在答辩时讲出来比背概念有说服力得多。3. 选课与成绩模块实现事务、冲突检测与批量录入3.1 选课接口的事务边界与容量校验选课是整套系统里唯一需要严格事务控制的操作。一次成功的选课要同时完成三件事检查课程是否已满、检查是否与已选课程时间冲突、写入选课记录。这三步必须在一个事务里完成否则会出现“容量检查通过但写入时已满”的超卖问题。// 选课核心逻辑事务内完成容量校验与写入 Transactional(rollbackFor Exception.class) public void enroll(Long studentId, Long courseId, String semester) { // 1. 行锁锁定课程记录防止并发超卖 Course course courseMapper.selectForUpdate(courseId); if (course null) { throw new BizException(课程不存在); } // 2. 统计当前已选人数status1 才算有效选课 int enrolled enrollmentMapper.countActive(courseId, semester); if (enrolled course.getCapacity()) { throw new BizException(课程容量已满); } // 3. 时间冲突检测查该生本学期已选课程的时间段 ListTimeSlot conflict enrollmentMapper.findConflictSlots( studentId, semester, course.getTimeSlot()); if (!conflict.isEmpty()) { throw new BizException(与已选课程时间冲突); } // 4. 写入选课记录唯一键兜底防重复 enrollmentMapper.insert(studentId, courseId, semester); }这段代码的关键在第一步的selectForUpdate。它会对课程行加排他锁把并发选同一门课的请求串行化容量校验才不会失效。很多同学只写了普通的 select压测时两个请求同时读到“还剩 1 个名额”结果都插入成功课程超卖。这个坑在答辩演示时如果被问到并发答不上来很扣分。时间冲突检测依赖课程表里的时间段字段。实际设计中一门课的时间可以存成“周一 3-4 节”这样的结构化字段冲突判断就是比较两个时间段是否有交集。课程设计阶段不必做复杂的排课算法把时间段简化为“星期 起止节次”两个字段冲突判断用区间重叠逻辑即可实现简单且能讲清楚。3.2 成绩批量录入与归档的幂等设计教师录入成绩的场景有两个特点一是批量操作一个班几十条记录一次提交二是可能重复提交网络抖动或误点都会导致同一批数据发两次。如果直接逐条 update重复提交会把已经改过的成绩再覆盖一遍虽然结果一样但审计日志会乱。更稳妥的做法是用“课程 学生”作为幂等键配合乐观锁版本号。-- 成绩录入带版本号的幂等更新 UPDATE enrollment SET score #{score}, version version 1, updated_at NOW() WHERE student_id #{studentId} AND course_id #{courseId} AND semester #{semester} AND status 1 AND version #{expectedVersion};更新影响行数为 0 时说明版本号不匹配或记录不存在应用层据此判断是重复提交还是数据异常。批量录入时把整批更新放在一个事务里任何一条失败就整体回滚避免出现“录了一半”的中间状态。这个设计在答辩时可以作为亮点讲幂等不是靠前端防重复点击而是靠数据库层的版本控制。成绩归档是另一个容易被忽略的点。学期结束后成绩需要从“可编辑”状态转为“只读”状态。我的做法是在课程表加一个archived标记归档操作把该学期所有选课记录的成绩锁定后续任何更新请求先检查归档标记已归档则直接拒绝。这样既保护了历史数据又不需要额外的归档表课程设计阶段足够用。3.3 权限隔离在 SQL 层的落地方式前面提到权限不能只靠前端。具体到 SQL 层教师查询成绩时必须带上teacher_id 当前登录教师的条件学生查询成绩时必须带上student_id 当前登录学生的条件。这个约束最好封装在 Mapper 层而不是让每个 Service 方法自己拼否则漏掉一处就是越权漏洞。// 教师查成绩强制拼接任教课程条件 public ListScoreVO listScoresByTeacher(Long teacherId, Long courseId) { return enrollmentMapper.selectScores( courseId, teacherId // SQL 中作为 course.teacher_id 的过滤条件 ); }对应的 SQL 里enrollment 表 join course 表where 条件同时包含 courseId 和 teacherId。这样即使前端传了一个不属于该教师的 courseId查询结果也是空而不是报错泄露信息。这种“查不到”比“无权限”更安全的处理方式在答辩时讲出来能体现安全意识。4. 避坑与排查课程设计里最容易翻车的五个点4.1 中文乱码从建库到连接串的全链路检查现象是学生姓名、课程名在页面上显示为问号或乱码。原因通常出在三个环节之一数据库字符集不是 utf8mb4、JDBC 连接串没指定字符集、表字段用了 latin1。解决顺序是先查库、再查表、最后查连接串。建库时统一CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci连接串加上useUnicodetruecharacterEncodingutf8两步做完基本不会再出问题。答辩前一定要用带生僻字的名字测一遍别等演示时才发现。4.2 选课超卖容量校验没加锁现象是课程容量 60实际选上 62 人。原因是容量校验和插入之间没有锁保护并发请求同时通过校验。解决办法是在事务内对课程行加SELECT ... FOR UPDATE把校验和写入串行化。如果不想用行锁也可以在课程表加一个已选人数字段用UPDATE course SET enrolled enrolled 1 WHERE enrolled capacity的原子更新来兜底影响行数为 0 就说明满了。两种方案选一种别混用。4.3 成绩统计把 NULL 当 0 算现象是及格率统计偏低明明有人没录成绩却被算成不及格。原因是AVG(score)和score 60都会把 NULL 排除或误判。正确做法是统计时显式过滤score IS NOT NULL未录入的记录单独计数。这个坑很隐蔽因为数据量小时看不出来答辩时老师问一句“没录成绩的怎么算”就露馅了。4.4 外键约束导致删除失败现象是删除课程时报外键冲突。原因是选课表里有该课程的记录。课程设计阶段不建议直接物理删除课程而是用状态字段标记“停开”选课记录保留。如果确实要删先删选课记录再删课程且必须在事务里做。更稳妥的做法是建表时外键加ON DELETE RESTRICT让数据库明确拒绝危险操作而不是级联删除把成绩一起干掉。4.5 事务不生效注解加错位置现象是Transactional加了但回滚不生效。常见原因有三个方法不是 public、同类内部调用绕过了代理、异常被 catch 后没重新抛出。排查时先确认方法修饰符再检查调用路径是否经过 Spring 代理最后看 catch 块里有没有throw。这个坑几乎每届都有人踩答辩前用一次故意抛异常的测试验证回滚比事后排查省事得多。5. 验收与答辩怎么用一套测试数据讲清设计价值验收这套系统我一般准备三组数据一组正常流程数据用来演示选课、录成绩、查成绩的完整链路一组边界数据包括容量刚好满的课程、时间冲突的两门课、成绩为 NULL 的记录一组异常数据用来演示重复选课被拒、越权查询返回空、已归档学期无法修改。三组数据覆盖了答辩老师最可能追问的场景演示时按“正常→边界→异常”的顺序走逻辑清晰且能主动暴露设计点。答辩陈述的时间通常只有五到八分钟结构比内容更重要。我的建议是按“业务痛点→表结构设计→关键实现→验证结果”四段讲。业务痛点用选课冲突和成绩误录两个场景切入三十秒讲完表结构只讲选课表这一个枢纽表说清唯一键和索引的设计理由关键实现挑事务选课和幂等录成绩两个点配合代码片段讲最后用测试数据的结果收尾证明冲突被拦住、重复提交不产生脏数据。下面这张验收清单可以直接对照检查每项都对应一个可演示的操作验收项操作预期结果重复选课拦截同一学生同学期选同一课两次第二次提示已选数据库无重复记录容量上限选满 60 人后再选提示容量已满人数不超时间冲突选两门同时间段课程第二门被拒并提示冲突成绩幂等同一批成绩提交两次数据不变版本号只增一次越权查询教师查非任教课程成绩返回空列表不报错不泄露归档保护修改已归档学期成绩拒绝更新并提示已归档这张表的价值在于每一项都能在答辩现场用一条 SQL 或一次点击验证老师问“你怎么保证不超卖”你直接演示选满后再选被拒比口头解释有说服力。我见过太多同学把时间花在界面美化上结果被问一句“并发怎么处理”就卡住很可惜。从那以后我每次带课程设计都要求学生在答辩前把这张验收表逐项跑一遍跑不通的项就是答辩时的雷。数据库课程设计的分数往往不取决于功能多少而取决于你能不能把一两个关键设计讲透、演示清楚。这套方案的表结构和实现逻辑可以直接拿去改把课程名、学期字段换成自己学校的口径就能跑。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 4:44:01 · 阅读 1.2k 教务管理系统数据库设计：选课冲突检测与成绩归档实战
简介这份资源是面向高校计算机相关专业学生的数据库课程设计实践案例围绕教务管理系统展开采用MySQL与Java技术栈帮助读者理解从需求分析、数据库设计到系统实现与测试的完整开发流程适合正在学习数据库原理与应用、Java编程等课程、需要完成课程设计或提升动手能力的学生参考使用。压缩包共28个文件约4.45MB包含9个java源文件与9个class编译文件、properties配置、jar依赖包、sql建库脚本及工程配置文件等覆盖源码、数据库脚本与工程结构便于直接导入运行和二次修改。目前已有2649人学习下载具备一定的参考热度。读者可从中获得教务管理场景下的数据库表结构设计思路、Java实现代码与工程组织方式并据此完成个性化改造与功能扩展为后续数据库应用开发打下实践基础。1. 教务管理系统课程设计从选课冲突到成绩归档的完整数据库方案每年选课季教务系统最怕的不是流量高峰而是同一门课被两个班同时抢、一个学生选了两门时间重叠的课、成绩录到一半发现学号对不上。数据库课程设计如果只做增删改查答辩时很难讲出深度真正能撑住场面的是把选课冲突检测、成绩归档、权限隔离这些教务场景里的硬骨头啃下来。这套基于 MySQL 与 Java 的教务管理系统面向课程设计、毕设开题和需要交付完整数据库方案的读者覆盖学生、教师、教务管理员三类角色核心表结构、事务边界和冲突校验逻辑都按可落地的标准设计不是玩具级 Demo。2. 需求与数据模型三类角色、六张核心表怎么定2.1 先定业务边界再画 E-R 图教务管理系统的需求看起来杂但落到数据库层面真正需要建模的实体并不多。我一般先把业务边界收在三件事上学生选课与退课、教师录入成绩、教务管理员维护课程与班级。超出这三件事的功能比如排课算法、教室调度课程设计阶段直接砍掉否则表结构会膨胀到无法在答辩前讲清楚。角色与权限的划分决定了后续表设计的粒度。学生只能看到自己的选课记录和成绩教师只能操作自己任教课程的成绩教务管理员拥有课程、班级、学生信息的维护权限。这个约束不是靠前端隐藏按钮实现的而是要在数据库层通过外键关联和查询条件双重保证。很多同学翻车就翻在这里前端把按钮藏了后端接口却裸奔答辩时老师随便构造一个请求就能改别人成绩。E-R 图的核心关系可以这样梳理学生与课程是多对多通过选课表关联教师与课程是一对多一门课由一个教师主讲班级与学生是一对多一个班包含多名学生。选课表是整张图的枢纽它同时承载了学生、课程、学期、成绩四个维度的信息也是后面冲突检测和成绩归档的主战场。2.2 六张核心表的结构与字段取舍表结构设计最忌讳一上来就堆字段。我的习惯是先确定每张表的“主键 业务唯一键 状态字段”三件套再往里填业务属性。下面这套结构经过课程设计场景验证字段数量控制在可讲清楚的范围内。-- 学生表学号作为业务唯一键自增 id 仅作内部关联 CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, stu_no VARCHAR(20) NOT NULL UNIQUE COMMENT 学号业务唯一标识, name VARCHAR(50) NOT NULL, class_id BIGINT NOT NULL COMMENT 所属班级, password VARCHAR(64) NOT NULL COMMENT 存储加盐哈希不存明文, status TINYINT DEFAULT 1 COMMENT 1在读 0离校, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_class (class_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 课程表课程号唯一容量字段用于选课人数上限校验 CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(100) NOT NULL, teacher_id BIGINT NOT NULL, credit DECIMAL(3,1) NOT NULL COMMENT 学分支持0.5, capacity INT NOT NULL DEFAULT 60 COMMENT 选课容量上限, semester VARCHAR(20) NOT NULL COMMENT 如2024-2025-1, KEY idx_teacher (teacher_id), KEY idx_semester (semester) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 选课表学生课程学期唯一防止重复选课 CREATE TABLE enrollment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, semester VARCHAR(20) NOT NULL, score DECIMAL(5,2) DEFAULT NULL COMMENT NULL表示未录入, status TINYINT DEFAULT 1 COMMENT 1已选 2已退, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_stu_course_sem (student_id, course_id, semester), KEY idx_course (course_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;教师表、班级表结构相对简单这里不展开。重点说三个设计取舍。第一选课表的唯一键包含学期字段因为同一门课可能在不同学期重复开设学生跨学期选同一门课是合法的但同一学期内重复选必须被数据库拦住。第二成绩字段允许为 NULL用 NULL 表示“未录入”而不是用 0 分这个区别在统计及格率时非常关键0 分和未录入是两回事。第三所有表统一用 utf8mb4避免学生姓名里的生僻字变成问号这是血泪经验答辩现场演示时名字乱码很尴尬。提示选课表的唯一键是防重复选课的最后一道防线应用层的“先查再插”在高并发下会失效必须靠数据库唯一约束兜底。2.3 索引不是越多越好按查询路径来建课程设计里常见的误区是给每个字段都加索引结果插入变慢、答辩时也说不清为什么建。正确的做法是按实际查询路径反推。教务系统的高频查询无非四类按学号查学生、按学期查课程、按学生查选课记录、按课程查选课名单。对应的索引在上面的建表语句里已经埋好student 表的 stu_no 唯一索引、course 表的 semester 索引、enrollment 表的 uk_stu_course_sem 联合唯一索引和 idx_course 索引。联合唯一索引 uk_stu_course_sem 的顺序有讲究。把 student_id 放在最前面是因为“查某个学生的所有选课”是最频繁的操作这个索引可以直接覆盖该查询。如果反过来把 course_id 放前面查学生选课就用不上这个索引只能走 idx_course 再过滤效率差一截。这类细节在答辩时讲出来比背概念有说服力得多。3. 选课与成绩模块实现事务、冲突检测与批量录入3.1 选课接口的事务边界与容量校验选课是整套系统里唯一需要严格事务控制的操作。一次成功的选课要同时完成三件事检查课程是否已满、检查是否与已选课程时间冲突、写入选课记录。这三步必须在一个事务里完成否则会出现“容量检查通过但写入时已满”的超卖问题。// 选课核心逻辑事务内完成容量校验与写入 Transactional(rollbackFor Exception.class) public void enroll(Long studentId, Long courseId, String semester) { // 1. 行锁锁定课程记录防止并发超卖 Course course courseMapper.selectForUpdate(courseId); if (course null) { throw new BizException(课程不存在); } // 2. 统计当前已选人数status1 才算有效选课 int enrolled enrollmentMapper.countActive(courseId, semester); if (enrolled course.getCapacity()) { throw new BizException(课程容量已满); } // 3. 时间冲突检测查该生本学期已选课程的时间段 ListTimeSlot conflict enrollmentMapper.findConflictSlots( studentId, semester, course.getTimeSlot()); if (!conflict.isEmpty()) { throw new BizException(与已选课程时间冲突); } // 4. 写入选课记录唯一键兜底防重复 enrollmentMapper.insert(studentId, courseId, semester); }这段代码的关键在第一步的selectForUpdate。它会对课程行加排他锁把并发选同一门课的请求串行化容量校验才不会失效。很多同学只写了普通的 select压测时两个请求同时读到“还剩 1 个名额”结果都插入成功课程超卖。这个坑在答辩演示时如果被问到并发答不上来很扣分。时间冲突检测依赖课程表里的时间段字段。实际设计中一门课的时间可以存成“周一 3-4 节”这样的结构化字段冲突判断就是比较两个时间段是否有交集。课程设计阶段不必做复杂的排课算法把时间段简化为“星期 起止节次”两个字段冲突判断用区间重叠逻辑即可实现简单且能讲清楚。3.2 成绩批量录入与归档的幂等设计教师录入成绩的场景有两个特点一是批量操作一个班几十条记录一次提交二是可能重复提交网络抖动或误点都会导致同一批数据发两次。如果直接逐条 update重复提交会把已经改过的成绩再覆盖一遍虽然结果一样但审计日志会乱。更稳妥的做法是用“课程 学生”作为幂等键配合乐观锁版本号。-- 成绩录入带版本号的幂等更新 UPDATE enrollment SET score #{score}, version version 1, updated_at NOW() WHERE student_id #{studentId} AND course_id #{courseId} AND semester #{semester} AND status 1 AND version #{expectedVersion};更新影响行数为 0 时说明版本号不匹配或记录不存在应用层据此判断是重复提交还是数据异常。批量录入时把整批更新放在一个事务里任何一条失败就整体回滚避免出现“录了一半”的中间状态。这个设计在答辩时可以作为亮点讲幂等不是靠前端防重复点击而是靠数据库层的版本控制。成绩归档是另一个容易被忽略的点。学期结束后成绩需要从“可编辑”状态转为“只读”状态。我的做法是在课程表加一个archived标记归档操作把该学期所有选课记录的成绩锁定后续任何更新请求先检查归档标记已归档则直接拒绝。这样既保护了历史数据又不需要额外的归档表课程设计阶段足够用。3.3 权限隔离在 SQL 层的落地方式前面提到权限不能只靠前端。具体到 SQL 层教师查询成绩时必须带上teacher_id 当前登录教师的条件学生查询成绩时必须带上student_id 当前登录学生的条件。这个约束最好封装在 Mapper 层而不是让每个 Service 方法自己拼否则漏掉一处就是越权漏洞。// 教师查成绩强制拼接任教课程条件 public ListScoreVO listScoresByTeacher(Long teacherId, Long courseId) { return enrollmentMapper.selectScores( courseId, teacherId // SQL 中作为 course.teacher_id 的过滤条件 ); }对应的 SQL 里enrollment 表 join course 表where 条件同时包含 courseId 和 teacherId。这样即使前端传了一个不属于该教师的 courseId查询结果也是空而不是报错泄露信息。这种“查不到”比“无权限”更安全的处理方式在答辩时讲出来能体现安全意识。4. 避坑与排查课程设计里最容易翻车的五个点4.1 中文乱码从建库到连接串的全链路检查现象是学生姓名、课程名在页面上显示为问号或乱码。原因通常出在三个环节之一数据库字符集不是 utf8mb4、JDBC 连接串没指定字符集、表字段用了 latin1。解决顺序是先查库、再查表、最后查连接串。建库时统一CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci连接串加上useUnicodetruecharacterEncodingutf8两步做完基本不会再出问题。答辩前一定要用带生僻字的名字测一遍别等演示时才发现。4.2 选课超卖容量校验没加锁现象是课程容量 60实际选上 62 人。原因是容量校验和插入之间没有锁保护并发请求同时通过校验。解决办法是在事务内对课程行加SELECT ... FOR UPDATE把校验和写入串行化。如果不想用行锁也可以在课程表加一个已选人数字段用UPDATE course SET enrolled enrolled 1 WHERE enrolled capacity的原子更新来兜底影响行数为 0 就说明满了。两种方案选一种别混用。4.3 成绩统计把 NULL 当 0 算现象是及格率统计偏低明明有人没录成绩却被算成不及格。原因是AVG(score)和score 60都会把 NULL 排除或误判。正确做法是统计时显式过滤score IS NOT NULL未录入的记录单独计数。这个坑很隐蔽因为数据量小时看不出来答辩时老师问一句“没录成绩的怎么算”就露馅了。4.4 外键约束导致删除失败现象是删除课程时报外键冲突。原因是选课表里有该课程的记录。课程设计阶段不建议直接物理删除课程而是用状态字段标记“停开”选课记录保留。如果确实要删先删选课记录再删课程且必须在事务里做。更稳妥的做法是建表时外键加ON DELETE RESTRICT让数据库明确拒绝危险操作而不是级联删除把成绩一起干掉。4.5 事务不生效注解加错位置现象是Transactional加了但回滚不生效。常见原因有三个方法不是 public、同类内部调用绕过了代理、异常被 catch 后没重新抛出。排查时先确认方法修饰符再检查调用路径是否经过 Spring 代理最后看 catch 块里有没有throw。这个坑几乎每届都有人踩答辩前用一次故意抛异常的测试验证回滚比事后排查省事得多。5. 验收与答辩怎么用一套测试数据讲清设计价值验收这套系统我一般准备三组数据一组正常流程数据用来演示选课、录成绩、查成绩的完整链路一组边界数据包括容量刚好满的课程、时间冲突的两门课、成绩为 NULL 的记录一组异常数据用来演示重复选课被拒、越权查询返回空、已归档学期无法修改。三组数据覆盖了答辩老师最可能追问的场景演示时按“正常→边界→异常”的顺序走逻辑清晰且能主动暴露设计点。答辩陈述的时间通常只有五到八分钟结构比内容更重要。我的建议是按“业务痛点→表结构设计→关键实现→验证结果”四段讲。业务痛点用选课冲突和成绩误录两个场景切入三十秒讲完表结构只讲选课表这一个枢纽表说清唯一键和索引的设计理由关键实现挑事务选课和幂等录成绩两个点配合代码片段讲最后用测试数据的结果收尾证明冲突被拦住、重复提交不产生脏数据。下面这张验收清单可以直接对照检查每项都对应一个可演示的操作验收项操作预期结果重复选课拦截同一学生同学期选同一课两次第二次提示已选数据库无重复记录容量上限选满 60 人后再选提示容量已满人数不超时间冲突选两门同时间段课程第二门被拒并提示冲突成绩幂等同一批成绩提交两次数据不变版本号只增一次越权查询教师查非任教课程成绩返回空列表不报错不泄露归档保护修改已归档学期成绩拒绝更新并提示已归档这张表的价值在于每一项都能在答辩现场用一条 SQL 或一次点击验证老师问“你怎么保证不超卖”你直接演示选满后再选被拒比口头解释有说服力。我见过太多同学把时间花在界面美化上结果被问一句“并发怎么处理”就卡住很可惜。从那以后我每次带课程设计都要求学生在答辩前把这张验收表逐项跑一遍跑不通的项就是答辩时的雷。数据库课程设计的分数往往不取决于功能多少而取决于你能不能把一两个关键设计讲透、演示清楚。这套方案的表结构和实现逻辑可以直接拿去改把课程名、学期字段换成自己学校的口径就能跑。希望帮到你。本文还有配套的精品资源点击获取