MySQL+Spring Boot教室管理系统数据库设计与排课冲突实现

简介这份压缩包面向学习数据库应用课程设计的学生与Web课程大作业开发者围绕教室管理系统给出可参考的完整项目素材帮助理解从需求分析、E-R建模到关系表设计、前后端联调与查询优化的实践路径。包内共39个文件约1.94MB以8个JSP页面、CSS与JavaScript静态资源、Java源码、SQL Server数据库文件及docx说明文档为主可据此梳理页面结构、业务逻辑与数据交互关系。已有2114人学习说明该案例在课程设计与入门级Web数据库项目中具有一定参考价值。读者可从中获得教室管理系统的目录组织、功能模块划分、数据库表与日志文件、前端样式脚本等线索用于对照自己的课程设计任务理解MVC分层、用户认证与SQL注入防范、并发访问控制及测试调试等关键知识点适合作为综合大作业的搭建参考与排错思路来源。1. 从一次教室冲突说起这套数据库课程设计要交付什么每学期排课那几天教务办公室最怕的不是课多而是教室撞车。某高校的数据库应用课程设计里教室管理系统几乎每年都会被选到题目听起来简单真做起来却容易在时间冲突、借用审批和统计报表上翻车。这份 web大作业 资源要解决的不是“能不能增删改查”而是把教室、课程、排课、借用四条数据主线理清楚让管理员能排课、教师能申请、学生能查空闲教室最后还能用一份建表脚本和一套接口把流程跑通。适合正在做数据库课程设计、Web 大作业或者需要交一份完整教室管理系统方案的人。读到后面你会发现重点不在页面多漂亮而在数据库约束和事务边界有没有兜住。2. 技术选型与总体架构为什么用 MySQL 加 Spring Boot 做教室管理系统这套教室管理系统用 MySQL 做数据底座后端 Spring Boot前端 Vue 加 Element Plus持久层用 MyBatis-Plus。这个组合不是因为它“流行”而是因为课程设计的时间通常被压缩在几周内数据库设计、接口联调、页面演示三件事必须同时推进框架层越轻越能把精力留给表结构、约束和事务。选型一旦偏重最后很容易出现页面能点、数据对不上、答辩一问就露怯的情况。2.1 技术栈取舍数据库课设别把重点丢在框架上数据库应用课程设计的评分点通常集中在实体关系是否合理、表结构是否规范、约束和索引有没有用对、业务 SQL 能不能跑通。前端页面是展示层后端框架是组织层真正决定系统是否站得住的是数据模型。用 Spring Boot 的好处是控制器、服务层、数据访问层边界清楚写事务和统一异常处理不费劲用 MyBatis-Plus 的好处是单表增删改查省代码复杂查询仍然能落到手写 SQL不会把数据库课设做成“框架配置课”。方案优点风险适用场景Spring Boot MyBatis-Plus Vue分层清楚接口调试方便复杂 SQL 可控需要理解事务和前后端分离课程设计、Web 大作业、需要演示完整流程Servlet JSP上手直接页面和数据放一起页面逻辑容易和业务逻辑混在一起课时少、只要求单机演示纯前端 本地存储演示快没有数据库约束答辩容易被问住只做界面原型不适合数据库课设我一般会建议把技术栈控制在“能跑通业务”的程度不追新也不为了显得复杂而堆中间件。配置上保持最简一个数据源、一个 MyBatis 映射路径、一个文件上传目录就够。下面这段配置是后端启动前的核心部分数据库名、用户名和密码按本机环境改。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/classroom_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: trueserver.port是后端服务端口前端开发时请求代理到这里spring.datasource.url里的classroom_db是数据库名建库脚本和表脚本要对应map-underscore-to-camel-case让数据库的room_no自动映射成 Java 的roomNo少了大量手写映射。密码不要照抄按本机环境改如果启动时报驱动类找不到先检查依赖有没有引入 MySQL 驱动而不是急着改业务代码。2.2 四层结构与角色边界管理员、教师、学生各自能做什么系统按表现层、控制层、服务层、数据访问层四层组织。表现层只负责展示和表单校验控制层收参数、做权限入口服务层写业务规则和事务数据访问层落 SQL。教室管理系统的业务规则并不复杂但角色边界要提前定清楚否则后面会出现教师能删教室、学生能审批借用这类权限漏洞。角色主要操作数据范围不能做的事管理员教室维护、课程维护、排课、审批、统计全部教室和排课数据不直接修改审批记录教师查看课表、提交教室借用申请、查看审批结果本人课程和本人申请不能排课、不能审批学生查询空闲教室、查看班级课表公开教室和本班课表不能提交借用、不能改数据角色边界落在接口上不落在页面上。页面隐藏按钮只是体验后端仍然要按角色拦截。比如/api/classroom/delete只允许管理员/api/borrow/apply只允许教师/api/classroom/free登录后都可用。这样做的好处是答辩时即使前端页面被绕过接口层仍然能兜住。2.3 工程目录与配置压缩包里的模块怎么对应这套资源的工程按“数据库脚本、后端服务、前端页面、说明文档”四块组织。后端按控制器、服务、实体、映射分层前端按页面和接口请求分层数据库脚本单独放方便先建库再启动。对照目录时不要一上来改包名先把建表脚本跑通再启动后端最后起前端顺序反了会在跨域和登录态上耗时间。目录/模块职责落地要点db建库、建表、初始化数据先执行建库再执行建表最后插初始化数据controller接口入口每个接口只做参数接收和权限注解service业务规则排课冲突、审批状态流转放在这里mapperSQL 映射复杂查询写 XML单表用 MyBatis-Plusweb前端页面登录、教室列表、排课、借用、统计五个主页面总体架构上浏览器请求先到前端路由再走接口请求模块后端控制层按角色做第一道拦截服务层做第二道业务校验数据库用主键、外键、唯一索引和事务做最后一道兜底。三层校验听起来多实际写起来并不复杂关键是别把校验全压在页面上。教室管理系统的很多问题不是“不会写”而是“只写了一半”。3. 数据库设计从 ER 图到 12 张核心表的落地细节数据库应用课程设计的重头戏在表结构。教室管理系统看着只有“教室”和“课程”实际要把教学楼、班级、教师、时间片、排课、借用申请、审批记录都串起来。表设计得粗后面冲突检测和统计查询就会变成补丁堆补丁表设计得过度复杂课程设计周期又撑不住。我的做法是先定四条主线再把每条主线落到表最后补约束和索引。3.1 实体与关系梳理教室、课程、排课、借用四条主线第一条主线是空间教学楼和教室是一对多教室属于某个教学楼教室里可以有容量、类型、设备说明。第二条主线是教学组织班级、教师、课程课程关联授课教师班级关联所属院系或专业方向。第三条主线是排课一条排课记录把课程、班级、教师、教室、学期、周次、星期、节次绑在一起它是冲突检测的核心。第四条主线是借用教师提交借用申请管理员审批审批通过后占用教室的某个时间段。这四条主线的关系可以这样理解教室是资源课程和班级是需求排课是正式占用借用是临时占用。正式占用和临时占用都要参与冲突检测否则会出现“课表上没课但教室被借走”的尴尬。实体关系不要求画得多漂亮但主键、外键、一对多、多对多的落点要清楚。用户和角色是多对多通过用户角色表拆开课程和班级如果存在一个课程多个班上课可以用排课表承载班级不必再建一张复杂的多对多表。12 张核心表可以这样分配表名作用关键字段sys_user登录用户id、username、password、role_id、statussys_role角色id、role_code、role_namesys_user_role用户角色关联user_id、role_idbuilding教学楼id、building_nameclassroom教室id、building_id、room_no、capacity、room_type、statusclass_group班级id、class_name、major_nameteacher教师id、user_id、teacher_no、teacher_namecourse课程id、course_code、course_name、teacher_id、credittime_slot时间片id、section_no、start_time、end_timeschedule排课id、course_id、class_id、teacher_id、classroom_id、semester、week_start、week_end、day_of_week、start_section、end_sectionborrow_apply借用申请id、classroom_id、applicant_id、semester、week_no、day_of_week、start_section、end_section、reason、statusapproval_record审批记录id、apply_id、approver_id、result、comment、created_at这张清单不是让你照抄字段名而是让你知道每张表为什么存在。time_slot用来统一节次时间前端展示“第 1-2 节”时不用在排课表里重复存开始时间和结束时间approval_record单独存审批流水避免把审批意见塞进借用申请表导致一条申请只能留一次意见。3.2 表结构与约束主键、外键、唯一索引和状态字段建表时最容易省掉的是外键和唯一索引。课程设计里数据量不大省掉外键也能跑但一旦删教室、删课程排课表里就会留下孤儿记录统计查询时数字对不上。我的建议是核心业务表加外键状态字段用统一枚举值能加唯一索引的地方不要只靠代码判断。-- 教室表同一教学楼内教室编号唯一 CREATE TABLE classroom ( id BIGINT PRIMARY KEY AUTO_INCREMENT, building_id BIGINT NOT NULL, room_no VARCHAR(20) NOT NULL, capacity INT NOT NULL DEFAULT 0, room_type VARCHAR(20) NOT NULL DEFAULT 普通教室, status TINYINT NOT NULL DEFAULT 1 COMMENT 1可用 0停用, remark VARCHAR(200), CONSTRAINT uk_room UNIQUE (building_id, room_no), CONSTRAINT fk_classroom_building FOREIGN KEY (building_id) REFERENCES building(id) ) COMMENT 教室信息; -- 排课表正式占用教室的教学安排 CREATE TABLE schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT NOT NULL, class_id BIGINT NOT NULL, teacher_id BIGINT NOT NULL, classroom_id BIGINT NOT NULL, semester VARCHAR(20) NOT NULL, week_start INT NOT NULL, week_end INT NOT NULL, day_of_week TINYINT NOT NULL COMMENT 1-7, start_section INT NOT NULL, end_section INT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_schedule_course FOREIGN KEY (course_id) REFERENCES course(id), CONSTRAINT fk_schedule_class FOREIGN KEY (class_id) REFERENCES class_group(id), CONSTRAINT fk_schedule_teacher FOREIGN KEY (teacher_id) REFERENCES teacher(id), CONSTRAINT fk_schedule_room FOREIGN KEY (classroom_id) REFERENCES classroom(id), INDEX idx_schedule_room_time (classroom_id, semester, day_of_week, week_start, week_end) ) COMMENT 排课记录; -- 借用申请表临时占用教室审批通过后才生效 CREATE TABLE borrow_apply ( id BIGINT PRIMARY KEY AUTO_INCREMENT, classroom_id BIGINT NOT NULL, applicant_id BIGINT NOT NULL, semester VARCHAR(20) NOT NULL, week_no INT NOT NULL, day_of_week TINYINT NOT NULL, start_section INT NOT NULL, end_section INT NOT NULL, reason VARCHAR(200) NOT NULL, status VARCHAR(20) NOT NULL DEFAULT PENDING COMMENT PENDING/APPROVED/REJECTED/CANCELED, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_borrow_room FOREIGN KEY (classroom_id) REFERENCES classroom(id), CONSTRAINT fk_borrow_user FOREIGN KEY (applicant_id) REFERENCES sys_user(id), INDEX idx_borrow_room_time (classroom_id, semester, week_no, day_of_week) ) COMMENT 教室借用申请;字段说明上status用TINYINT还是VARCHAR取决于业务。教室状态只有启用和停用用TINYINT足够借用申请有多个状态用VARCHAR更直观答辩时也容易讲清楚。week_start、week_end表示课程持续的教学周范围day_of_week表示星期几start_section、end_section表示节次区间。排课冲突检测不是判断“节次相等”而是判断两个区间是否重叠所以字段要成对存起止值。注意外键约束在课程设计里不是负担而是防止脏数据的最后一道门。如果答辩环境不允许外键至少要在服务层补删除前检查并把检查写进说明文档。3.3 冲突检测 SQL同一时间同一教室只能有一节课冲突检测的核心是“同一教室、同一学期、同一天、周次重叠、节次重叠”。这四个条件缺一个都会漏判。下面这条 SQL 查排课表里的正式冲突参数依次是教室 ID、学期、星期几、新排课的周次起止、新排课的节次起止。SELECT COUNT(1) FROM schedule WHERE classroom_id #{classroomId} AND semester #{semester} AND day_of_week #{dayOfWeek} AND week_start #{weekEnd} AND week_end #{weekStart} AND start_section #{endSection} AND end_section #{startSection};week_start 新周次结束和week_end 新周次开始表示两个周次区间有交集start_section 新节次结束和end_section 新节次开始表示两个节次区间有交集。注意这里用的是小于和大于不是小于等于因为“第 1-2 节”和“第 2-3 节”在第 2 节上是重叠的但如果新排课结束节次等于已有开始节次说明首尾相接不重叠。很多同学在这里把条件写成start_section endSection AND end_section startSection结果相邻节次也判冲突演示时明明没撞车却排不进去。借用申请也要参与检测但只查已通过的申请。SQL 结构类似把表换成borrow_apply周次字段换成week_no状态条件加status APPROVED。正式排课和借用申请是两张表冲突检测要在同一个事务里查两次先查排课表再查已通过的借用表。两次查询之间如果有并发审批仍然可能插进来所以还要在服务层锁教室行下面第 4 章会写。3.4 初始化数据与测试数据让演示不冷场初始化数据不是为了好看是为了让答辩现场能立刻演示冲突。至少准备三个教学楼、十个教室、五门课程、三个班级、两个教师账号、一个管理员账号再准备一条已排课记录和一条已通过的借用记录。测试数据里要故意留一个“同一教室同一时间”的用例演示时先查空闲教室再提交冲突排课页面弹出冲突提示这比空库点增删改查有说服力。INSERT INTO building (building_name) VALUES (第一教学楼), (第二教学楼); INSERT INTO classroom (building_id, room_no, capacity, room_type, status) VALUES (1, A101, 60, 普通教室, 1), (1, A102, 40, 普通教室, 1), (2, B201, 120, 多媒体教室, 1); INSERT INTO schedule (course_id, class_id, teacher_id, classroom_id, semester, week_start, week_end, day_of_week, start_section, end_section) VALUES (1, 1, 1, 1, 2025-2026-1, 1, 16, 1, 1, 2);semester用统一的学期字符串前端下拉框和统计查询都按这个值过滤week_start和week_end用 1 到 16 周演示时不用真的等到某一周。初始化数据要和建表脚本分开先建表再插数据否则外键顺序会报错。测试数据里不要把时间片写死成“1-2 节”要留出“3-4 节”“5-6 节”的教室空闲时间学生查空闲教室时才有结果。4. 核心模块实现排课、借用审批、查询统计三条链路模块实现要围绕业务链路写不要按“增删改查”平铺。排课链路的核心是冲突检测和事务借用审批链路的核心是状态机统计链路的核心是聚合查询不重复计数。三条链路都跑通教室管理系统才算完整。权限和登录放在最后是因为它贯穿所有接口但不应该抢业务代码的篇幅。4.1 排课模块时间片建模与事务内冲突校验排课接口收的参数包括课程、班级、教师、教室、学期、周次起止、星期、节次起止。服务层先锁教室行再查正式排课冲突和已通过借用冲突最后插入排课记录。锁教室行的目的是防止两个管理员同时给同一教室排课一个查完没冲突另一个也查完没冲突最后两条都插进去。课程设计的数据量不大但这种并发场景在答辩时很容易被追问。Transactional(rollbackFor Exception.class) public void createSchedule(ScheduleDTO dto) { // 锁定教室行避免并发排课同时通过冲突检测 classroomMapper.selectByIdForUpdate(dto.getClassroomId()); int scheduleConflict scheduleMapper.countConflict( dto.getClassroomId(), dto.getSemester(), dto.getDayOfWeek(), dto.getWeekStart(), dto.getWeekEnd(), dto.getStartSection(), dto.getEndSection() ); if (scheduleConflict 0) { throw new BizException(该教室在所选周次和节次已有课程); } int borrowConflict borrowMapper.countApprovedConflict( dto.getClassroomId(), dto.getSemester(), dto.getWeekStart(), dto.getWeekEnd(), dto.getDayOfWeek(), dto.getStartSection(), dto.getEndSection() ); if (borrowConflict 0) { throw new BizException(该教室在所选时间已有通过的借用申请); } Schedule entity new Schedule(); entity.setCourseId(dto.getCourseId()); entity.setClassId(dto.getClassId()); entity.setTeacherId(dto.getTeacherId()); entity.setClassroomId(dto.getClassroomId()); entity.setSemester(dto.getSemester()); entity.setWeekStart(dto.getWeekStart()); entity.setWeekEnd(dto.getWeekEnd()); entity.setDayOfWeek(dto.getDayOfWeek()); entity.setStartSection(dto.getStartSection()); entity.setEndSection(dto.getEndSection()); scheduleMapper.insert(entity); }Transactional(rollbackFor Exception.class)保证冲突提示抛出后不会留下半条数据selectByIdForUpdate对应的 SQL 是SELECT * FROM classroom WHERE id ? FOR UPDATE它锁住教室行让同一教室的排课请求排队执行。countConflict的参数就是第 3 章那条 SQL 的参数顺序weekStart、weekEnd传新排课的周次范围startSection、endSection传新排课的节次范围。异常里的提示要写清楚是“已有课程”还是“已有借用”答辩时演示能直接看出系统拦的是哪类冲突。前端提交时不要只传教室编号要把学期、周次、星期、节次一起传否则后端无法判断冲突。下面这段请求代码是排课表单提交的核心form里已经做了必填校验提交后按后端返回的code决定提示。// 排课提交后端返回 code0 表示成功其余按 message 提示 async function submitSchedule(form) { const res await request.post(/api/schedule, { courseId: form.courseId, classId: form.classId, teacherId: form.teacherId, classroomId: form.classroomId, semester: form.semester, weekStart: form.weekRange[0], weekEnd: form.weekRange[1], dayOfWeek: form.dayOfWeek, startSection: form.sectionRange[0], endSection: form.sectionRange[1] }) if (res.code ! 0) { ElMessage.error(res.message || 排课失败) return false } ElMessage.success(排课成功) return true }weekRange和sectionRange是前端区间选择器的值拆成起止两个字段传给后端semester从当前学期下拉框取不要写死。返回code的约定要在接口文档里写清楚避免前端把业务失败当网络错误处理。4.2 借用审批模块申请、审批、释放的状态机借用申请有四个状态待审批、已通过、已驳回、已取消。教师提交申请后是待审批管理员审批通过后变已通过同时占用教室时间驳回后变已驳回不占用教师取消待审批的申请变已取消。审批通过时不能只改状态还要再查一次冲突因为申请提交后可能已经有排课插进来。当前状态操作下一状态校验无教师提交PENDING教室可用、时间合法PENDING管理员通过APPROVED再次查排课和已通过借用冲突PENDING管理员驳回REJECTED必须填驳回原因PENDING教师取消CANCELED只能取消本人申请APPROVED管理员撤销CANCELED记录审批流水审批接口要在事务里做三件事锁申请行、锁教室行、查冲突并更新状态。锁申请行防止同一申请被重复审批锁教室行防止审批通过时和排课插入撞车。审批记录表单独插入一条流水result存APPROVED或REJECTEDcomment存意见。不要直接把审批意见更新到申请表的reason字段否则教师提交的理由会被覆盖。4.3 查询统计模块教室利用率和空闲教室查询统计查询最容易出两个问题重复计数和笛卡尔积。教室利用率可以按“已占用节次 / 可排课总节次”算已占用节次来自排课表和已通过借用表总节次按教室数乘以周数乘以每天节次数。如果直接多表 join 再COUNT一个教室有多条排课时会被放大算出来的利用率可能超过 100%。-- 按教室统计已占用节次排课和已通过借用分两条子查询再汇总 SELECT room_id, SUM(used_sections) AS used_sections FROM ( SELECT classroom_id AS room_id, SUM(end_section - start_section 1) * (week_end - week_start 1) AS used_sections FROM schedule WHERE semester #{semester} GROUP BY classroom_id UNION ALL SELECT classroom_id AS room_id, SUM(end_section - start_section 1) AS used_sections FROM borrow_apply WHERE semester #{semester} AND status APPROVED GROUP BY classroom_id ) t GROUP BY room_id;子查询先按教室聚合再在外层汇总避免排课和借用两条明细直接 join 造成乘法放大。空闲教室查询用NOT EXISTS更稳给定学期、星期、节次区间排除排课表和已通过借用表中时间重叠的教室。NOT EXISTS的语义是“只要存在一条冲突就不选这个教室”比左连接后判空更直观也不容易漏条件。4.4 权限与登录基于角色的接口拦截登录成功后后端返回用户信息和角色码前端按角色渲染菜单后端用拦截器按接口路径和角色码做校验。管理员可以访问/api/classroom/**、/api/schedule/**、/api/approval/**教师可以访问/api/borrow/apply、/api/schedule/my学生可以访问/api/classroom/free、/api/schedule/class。拦截器里只做粗粒度控制细粒度数据范围在服务层做比如教师只能查自己的借用申请。public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String uri request.getRequestURI(); String role (String) request.getSession().getAttribute(roleCode); if (role null) { response.setStatus(401); return false; } if (uri.startsWith(/api/approval) !ADMIN.equals(role)) { response.setStatus(403); return false; } if (uri.startsWith(/api/borrow/apply) !TEACHER.equals(role)) { response.setStatus(403); return false; } return true; }这段拦截器只演示路径级权限roleCode从会话里取实际项目里可以换成令牌解析。401表示未登录403表示已登录但无权限前端要分开处理401 跳登录页403 提示“无权限操作”。不要把权限判断只写在前端菜单里否则答辩时换一个接口工具就能绕过。5. 避坑与常见问题排查五个最容易翻车的点教室管理系统的代码量不算大翻车点却很集中。下面五条是我在课程设计里见过最多的问题每一条都按“现象、原因、解决”拆开写。答辩前照着过一遍能省掉不少现场调试时间。5.1 时间字段用字符串存冲突检测直接失效现象是排课页面能提交冲突检测偶尔拦得住、偶尔拦不住换一个教室就失灵。原因通常是把start_section、end_section存成了字符串比较时按字典序走“10”会排在“2”前面区间重叠判断自然错。还有一种是把周次存成“1-16周”这样的文本SQL 里无法直接比较起止。解决方式是把周次和节次拆成整型起止字段前端展示时再拼成文本。建表时用INT或TINYINT冲突 SQL 用数值比较不要用LIKE或字符串截取。已经建了字符串字段的加字段迁移数据别在 SQL 里套CAST硬撑索引会用不上。5.2 外键缺失导致删教室后排课成孤儿记录现象是管理员删了一个停用教室课表页面还能查出这个教室的排课统计利用率时教室名为空。原因是排课表没有外键或者外键没开级联检查删除接口只删了教室表。解决方式有两个核心表加外键删除前检查引用或者服务层做删除前校验存在排课和借用时拒绝删除提示“先处理关联记录”。课程设计里我更推荐后者加外键双保险外键保证数据库层不出现孤儿记录服务层给出可读提示。删除教室不要做物理删除改成status 0停用历史排课还能保留。5.3 审批并发重复占用事务边界没包住现象是两个管理员同时点通过两条审批都成功同一教室同一时间出现两条已通过借用。原因是审批服务方法没加事务或者冲突查询在事务外查的时候都没冲突更新的时候都成功。解决方式是把“锁申请行、锁教室行、查冲突、更新状态、写审批记录”放在同一个Transactional方法里冲突查询用当前连接不要另起线程。申请行锁用SELECT ... FOR UPDATE教室行锁同理。事务方法不要吞异常捕获后要重新抛出否则回滚不了。5.4 统计查询笛卡尔积利用率算出来大于 100%现象是教室利用率页面出现 120%、300% 这种数字换一个学期又正常。原因是排课表和借用表直接 join再对节次求和一个教室有多条排课时每条借用记录都会被重复计算。解决方式是先分表聚合再汇总或者用UNION ALL把两类占用转成同一结构后再按教室分组。统计 SQL 写完拿三条排课、两条借用手工算一遍和页面结果对得上再继续。别迷信DISTINCT它只能去重行去不了求和放大。5.5 演示环境数据太干净答辩现场查不出冲突现象是答辩时演示排课随便选一个时间都成功老师问“冲突怎么拦”时现场造数据结果手忙脚乱。原因是初始化数据只有一条排课空闲教室太多。解决方式是准备一组固定演示数据第一教学楼 A101 周一第 1-2 节已有课A101 第 3-4 节已有一条通过的借用B201 周五第 5-6 节空闲。演示顺序固定为“查空闲教室、排冲突课、看冲突提示、审批借用、再排课再次冲突”。数据脚本和演示脚本放在说明文档里换机器也能复现。血泪经验是答辩现场最怕的不是功能少而是演示路径临时想。6. 验收与答辩用一份演示脚本把方案讲清楚验收前先按四项清单自查数据库能一键建库建表并插入初始化数据后端能启动且接口文档里的核心接口都能调通前端五个主页面能走通登录、教室、排课、借用、统计说明文档里有 ER 说明、表结构说明、演示账号和演示步骤。四项里任何一项靠现场记忆答辩都会打折扣。下面这张表可以直接当验收清单用。验收项检查内容通过标准数据库建库、建表、初始化数据一条命令跑完无外键报错接口登录、排课、借用、审批、统计冲突用例能返回明确提示页面五个主页面不同角色菜单不同越权接口返回 403文档ER 说明、表结构、演示步骤照着文档能复现演示答辩演示不要从登录页开始平铺先讲业务背景再直接进排课冲突用例。第一步展示 A101 已有排课第二步提交同一教室同一时间的新排课页面弹出冲突提示第三步展示已通过借用占用的时间段再排课再次被拦第四步进审批页面通过一条新申请回排课页面验证冲突第五步打开统计页面说明利用率的分母和分子怎么算。整个流程控制在五到七分钟剩下的时间留给追问。常见追问一般集中在三处冲突检测为什么用区间重叠而不是相等判断审批通过时为什么要再查一次冲突统计 SQL 怎么避免重复计数。回答时落到字段和事务上不要背概念。比如冲突检测就说“周次区间和节次区间分别判断交集四个条件同时满足才算冲突”审批再说“申请提交后可能有新排课插进来所以通过时要再校验一次”。如果老师问为什么不用数据库唯一索引直接拦冲突可以回答“区间重叠不是等值唯一唯一索引管不住跨周次和跨节次的交集所以用事务加查询锁”。从那以后我每次带课程设计都强制先跑一遍冲突用例再让学生演示审批并发最后才看页面。顺序反过来很容易被一个空库演示蒙过去。这套资源的建表脚本、后端接口和前端页面按第 2 章的目录对应先跑脚本再照着第 6 章的演示顺序走一遍课程设计的基本盘就稳了。希望帮到你。本文还有配套的精品资源点击获取