简介师生健康信息管理系统是一款面向高校的完整毕业设计项目基于Spring Boot框架开发系统包含管理员与学生两种角色并采用前后台分离的设计模式。后台管理功能覆盖学生管理、教师管理、疫情问卷管理、问卷调查管理、返校信息管理等多个模块前台则支持学生进行健康数据填报、问卷作答与返校申请等操作整体业务流程清晰完整。压缩包内共包含5个文件除源代码压缩包和SQL数据库脚本外还配有万字毕业设计文档、答辩用PPT以及说明文档资源总大小为13.91MB能够满足从代码部署到论文撰写的全流程需求。目前该资源已有32人浏览学习适合正在准备毕业设计或课程设计的高校学生也可供初级Java开发者学习项目结构设计与功能实现参考。通过这份资料读者可以快速掌握一套多角色管理系统的完整搭建过程了解数据库表设计、接口调用、数据统计等核心技术的实际应用。1. 师生健康信息管理系统在校园信息化里到底解决什么问题师生健康信息管理系统是数据库课程设计和软件工程课设里出现频率很高的题目交付物往往写作源码、数据库、万字文档、PPT四个部分。系统的业务线条并不复杂角色却不少系统管理员、校医、辅导员、学生都要在同一套平台里看到各自关心的数据最终目标是把个人健康档案、体检记录、每日健康申报、异常症状处置整合成一条可追踪、可统计的信息链。这类课设最常见的丢分点集中在三处数据库表与外键关系说不清异常数据从申报到处置的状态流转走不通统计报表口径和文档截图对不上。换句话说代码只是实现的前半段后半段是文档、数据库脚本、PPT在讲同一个故事。下面按一套成熟可复现的课设方案展开从业务建模和表结构入手给出核心源码实现再讲统计查询的 SQL 写法最后聊万字文档和 PPT 怎么打包才能过答辩。目标读者是正在做师生健康管理课设的学生以及需要快速搭起同类管理信息系统的开发者。2. 数据库设计先行把健康信息拆成六张核心表2.1 角色权限与业务边界谁在往系统里填数据在做表结构之前先列一遍角色角色定清楚表的归属才不打架。系统管理员的职责是维护班级、账号和权限分配不直接写健康记录校医要处理异常申报并回填处置结果辅导员可以查看本班学生申报率和健康档案但不应修改体检数据学生只提交每日体温、症状维护自己的基础档案。对角色的处理用 sys_user 表中的 user_type 字段区分身份不要为每个角色单独建用户表否则权限校验、登录逻辑和外键关联都要成倍膨胀。权限控制在课设阶段做到菜单级就够登录后根据 user_type 决定前端路由后端接口同样做一次拦截。这里有一个容易在答辩时被追问的点学生只能改自己的档案不能把 user_id 换成别人来绕过限制。前端隐藏按钮不算权限控制真正要做的是在 Service 层拿 session 中的登录用户 ID 和请求参数中的 ID 比对不一致直接拒绝。这条规则会在后面源码实现里体现。2.2 表拆分用户、班级、档案、体检、申报、异常各管一段一个代码量在 800 到 1000 行左右的课设数据库拆六张表足够拆分思路是把主数据和行为数据分开。班级、用户、健康档案属于不太变化的静态数据体检记录、每日健康申报、异常处置属于持续写入的流水数据两者混在一张表里修改健康档案会把历史申报也盖掉数据追溯就无从谈起。表名职责关键外键或约束class_info班级信息含年级和辅导员class_id 主键sys_user管理员、校医、教师、学生共用账号表class_id 外键关联班级health_record个人基础健康档案血型、过敏史、病史user_id 唯一键physical_exam身高、体重、视力、血压等体检记录user_id 外键exam_date 可重复daily_report每日健康申报流水user_id report_date 联合唯一health_abnormal异常症状处置记录user_id 外键status 记录处理进度daily_report 和 health_abnormal 是业务上最需要注意的两张表。每日申报在插入时根据体温和症状决定是否同时写入一条异常记录异常表不单独接收用户提交只由申报逻辑生成。这样报表统计健康异常率时只要在 health_abnormal 上做 group by不需要再到 daily_report 中做二次筛选。2.3 MySQL 建表脚本先跑通 DDL 再谈后续下面是完整的建表 SQLMySQL 5.7 和 8.0 都可以直接执行。数据类型按课设常用方式选把约束写清楚比追求极致容量更重要。CREATE TABLE class_info ( class_id INT PRIMARY KEY AUTO_INCREMENT, class_name VARCHAR(100) NOT NULL, grade VARCHAR(20), head_teacher VARCHAR(50) ); CREATE TABLE sys_user ( user_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(255) NOT NULL, real_name VARCHAR(50) NOT NULL, user_type VARCHAR(10) NOT NULL DEFAULT STUDENT, class_id INT, gender VARCHAR(4), phone VARCHAR(20), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (class_id) REFERENCES class_info(class_id) ); CREATE TABLE health_record ( record_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL UNIQUE, blood_type VARCHAR(10), allergy VARCHAR(500), past_history VARCHAR(500), disabled_flag VARCHAR(4) DEFAULT 否, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES sys_user(user_id) ); -- 每日申报同一人同一天只能有一条记录 CREATE TABLE daily_report ( report_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, report_date DATE NOT NULL, temperature DECIMAL(4,2), symptom VARCHAR(255), is_abnormal CHAR(1) DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_date (user_id, report_date), FOREIGN KEY (user_id) REFERENCES sys_user(user_id) ); -- 异常处置一天可多条保留每次跟进痕迹 CREATE TABLE health_abnormal ( abnormal_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, report_date DATE NOT NULL, symptom VARCHAR(300), temperature DECIMAL(4,2), status VARCHAR(20) DEFAULT 待处理, handle_person VARCHAR(50), handle_time DATETIME, remark VARCHAR(500), FOREIGN KEY (user_id) REFERENCES sys_user(user_id) );这里有两个容易忽略的设计细节。daily_report 的联合唯一键 uk_user_date 保证同一个人同一天只能有一条申报记录重复申报时用 ON DUPLICATE KEY UPDATE 更新原记录即可不会在报表里出现重复行。health_abnormal 不加唯一约束因为同一个人的一次异常可能被校医多次跟进每次跟进都要留下独立记录。初始化数据至少建三个账号管理员、一个校医、一个绑定了班级的学生。密码字段在课设里直接存 MD5 值可以接受但要知道企业项目里应当换成 BCryptINSERT INTO class_info (class_name, grade, head_teacher) VALUES (软件2101班, 大三, 王老师); INSERT INTO sys_user (username, password, real_name, user_type, class_id) VALUES (admin, MD5(123456), 系统管理员, ADMIN, NULL), (doctor01, MD5(123456), 校医李华, DOCTOR, NULL), (stu001, MD5(123456), 张明, STUDENT, 1);执行完建表后用 Navicat 或 MySQL Workbench 导出 ER 图截图。这张截图后面要进万字文档和 PPT 的数据库设计章节与交付包里的 SQL 脚本保持一致答辩时这一张图能回答掉数据库表结构的大部分提问。3. 源码实现健康档案增删改查与异常状态流转3.1 工程分层controller、service、mapper 各自管什么师生健康管理系统源码的常见组织方式是 Spring Boot MyBatis页面部分用 Vue 或 JSP 都能运行。分层原则很固定Controller 只做参数接收和响应封装Service 放健康规则判断Mapper 写 SQL。把业务判断放在 Controller 里是课设中最常见的坏味道一旦异常状态规则变化你不得不在每个接口里改重复逻辑。源码包结构建议分成 entity、mapper、service、controller 四层。entity 放置与表字段对应的实体类mapper 负责单表增删改查service 负责跨表操作比如申报时同时写入 daily_report 和 health_abnormal。下面展示健康档案模块最核心的查询与保存接口。3.2 健康档案的查询与保存接口RestController RequestMapping(/health) public class HealthRecordController { private final HealthRecordMapper recordMapper; public HealthRecordController(HealthRecordMapper recordMapper) { this.recordMapper recordMapper; } // 查询某个用户的健康档案 GetMapping(/record/{userId}) public Result getRecord(PathVariable Integer userId) { HealthRecord record recordMapper.selectByUserId(userId); if (record null) { return Result.error(该用户尚未建立健康档案); } return Result.success(record); } // 新增或更新有记录走更新没有走插入 PostMapping(/record/save) public Result saveRecord(RequestBody HealthRecord record) { Integer userId record.getUserId(); if (userId null) { return Result.error(userId 不能为空); } int cnt recordMapper.countByUserId(userId); if (cnt 0) { recordMapper.updateByUserId(record); return Result.success(档案已更新); } recordMapper.insert(record); return Result.success(档案已创建); } }代码里用 countByUserId 判断是否已有记录而不是先把整条记录查出来再判断原因是只需要统计值时一次 count 查询比加载整行数据开销小很多代码也更直接。updateByUserId 在 XML 里对应UPDATE health_record SET ... WHERE user_id #{userId}这个操作依赖 health_record 表上 user_id 的唯一约束。并发下如果同时提交两条新增请求唯一约束会拦截重复插入此时应该捕获 DuplicateKeyException 后执行 update而不是放开唯一约束否则数据一致性就没了。3.3 每日健康申报体温阈值自动写异常表每日申报是整个系统里业务区分度最高的功能。页面提交 userId、reportDate、temperature、symptom 四个字段后端判定体温大于等于 37.3 度或者症状不为空就自动落一条异常记录到 health_abnormal并把状态设为待处理。对应实现如下Service public class DailyReportService { private final DailyReportMapper reportMapper; private final HealthAbnormalMapper abnormalMapper; Transactional public void submitReport(Integer userId, LocalDate reportDate, BigDecimal temperature, String symptom) { // 健康判定规则体温阈值或症状文本非空 boolean abnormal temperature.compareTo(new BigDecimal(37.3)) 0 || (symptom ! null !symptom.trim().isEmpty()); DailyReport report new DailyReport(); report.setUserId(userId); report.setReportDate(reportDate); report.setTemperature(temperature); report.setSymptom(symptom); report.setIsAbnormal(abnormal ? 1 : 0); reportMapper.insertOrUpdate(report); if (abnormal) { HealthAbnormal abnormalRecord new HealthAbnormal(); abnormalRecord.setUserId(userId); abnormalRecord.setReportDate(reportDate); abnormalRecord.setTemperature(temperature); abnormalRecord.setSymptom(symptom); abnormalRecord.setStatus(待处理); abnormalMapper.insert(abnormalRecord); } } }Transactional 声明开启事务保证申报记录和异常表写入要么同时成功要么同时回滚。insertOrUpdate 对应 MySQL 的 ON DUPLICATE KEY UPDATE必须依赖 daily_report 表上的联合唯一键否则重复提交会变成两条申报记录后续报表做去重就要写额外 SQL。health_abnormal 的状态流转建议用 Service 层常量类维护不要在 Controller 里散落魔法字符串状态字段值含义谁触发待处理系统刚生成校医还没接手申报接口自动写入已处理校医完成健康评估校医更新接口已排除复查后排除疑似情况校医更新接口备注里可写明依据把这三种状态集中定义后续做状态统计的 SQL 时where 条件直接引用常量避免口径分散到多个文件里这也是源码规范里值得写进万字文档的一条。4. 统计查询与报表口径让数据库输出答辩要用的数据4.1 按班级统计申报率一条 SQL 同时算两个率数据库课程设计里的报表题最容易翻车核心原因是多表 join 时记录数膨胀count 出来一堆重复值。下面是按班级统计某日申报率和异常率的 SQL注意使用 COUNT(DISTINCT) 去重SELECT ci.class_id, ci.class_name, COUNT(DISTINCT su.user_id) AS total_students, COUNT(DISTINCT dr.report_id) AS reported_students, ROUND(COUNT(DISTINCT dr.report_id) / NULLIF(COUNT(DISTINCT su.user_id), 0) * 100, 1) AS report_rate, COUNT(DISTINCT ha.abnormal_id) AS abnormal_cnt FROM class_info ci LEFT JOIN sys_user su ON su.class_id ci.class_id AND su.user_type STUDENT LEFT JOIN daily_report dr ON dr.user_id su.user_id AND dr.report_date 2025-06-10 LEFT JOIN health_abnormal ha ON ha.user_id su.user_id AND ha.report_date 2025-06-10 GROUP BY ci.class_id, ci.class_name ORDER BY report_rate DESC;查询执行顺序先拿班级做驱动表关联出全部学生再关联 daily_report连接条件里带上日期确保某一天的申报不会污染其他日期最后关联 health_abnormal同样带日期条件拿到当天异常数。NULLIF 把 zero 转成 NULL避免除数不能为零的报错。报表页面展示时report_rate 和 abnormal_cnt 这两个字段就是文档和 PPT 里要截的图口径依据就是这条 SQL不要前端自己再算一遍否则前后端结果对不上答辩现场会非常被动。4.2 近30天异常趋势和症状分布趋势图的数据接口不需要前端拼 JSON后端直接返回 SQL 分组结果前端拿到数组后渲染折线即可-- 近30天每日新增异常数量 SELECT report_date, COUNT(*) AS abnormal_increment FROM health_abnormal WHERE report_date DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY report_date ORDER BY report_date; -- 症状类型分布课设级分析直接统计症状字段文本 SELECT symptom, COUNT(*) AS cnt FROM health_abnormal GROUP BY symptom ORDER BY cnt DESC LIMIT 10;对 symptom 做 GROUP BY 会把“发热”“发烧”这类近似文本统计成两个分类。时间充裕就在申报页面做成下拉框固定症状词从源头统一口径时间紧张就保留文本统计在文档里说明这是文本粒度统计。两种做法都能自圆其说但一套交付物里不能出现两套口径。4.3 索引设计给报表查询补上两个组合索引趋势查询在 health_abnormal 上用 report_date 做范围过滤如果表里只有主键索引数据量到几万条时 MySQL 会走全表扫描。常见做法是补两个组合索引ALTER TABLE health_abnormal ADD INDEX idx_abnormal_date_status (report_date, status); ALTER TABLE daily_report ADD INDEX idx_report_date (report_date);idx_abnormal_date_status 覆盖了按日期过滤、按状态过滤、日期加状态组合过滤三个场景。虽然 health_abnormal 写入频率低但报表和答辩统计都依赖这个索引建立后执行计划的 type 会从 ALL 变为 rangeexplain 结果截图放进文档就能作为数据库优化证据。答辩时如果被问“为什么用组合索引而不是两个单列索引”可以说MySQL 8.0 之后虽然引入了索引合并但组合索引在范围查询和排序上的表现更稳定且索引数量更少写入开销也更小。这句话能挡住绝大多数追问。5. 从源码到交付万字文档与 PPT 怎么编排不返工5.1 万字文档先锁定数据库设计和系统测试万字文档不能最后再写最合理的做法是先写数据库设计再写需求分析最后补测试章节。数据库设计写好代码实现就有据可依文档里贴的表结构只要和交付的 SQL 脚本一致答辩时就不会出现“文档里这么说代码却那么写”的情况。文档里三个核心章节和配套产物的对应关系如下文档章节要写的内容配套产物需求分析角色用例图、功能性需求与非功能性需求用例图截图数据库设计概念结构设计、逻辑结构设计、物理设计建表脚本、ER图、索引说明系统测试每个功能模块的测试用例、步骤、结果功能截图、SQL 执行结果测试章节是大部分人容易忽略的部分。用验证 SQL 查出来的数据结果配一张前端页面截图构成一个完整的测试用例。三个用例就够撑起测试章节正常申报、异常申报自动写入、按班级统计报表。5.2 PPT 主线按一条操作链来演示PPT 建议控制在 12 页以内主线按操作链走管理员登录并分配账号、学生提交每日申报、申报流水写入、统计报表展示、校医处理异常、异常状态更新。每次演示都走这条链路每一页 PPT 截图和现场演示页面顺序保持一致不要 ppt 讲页面 A、手却点到页面 B。演示数据要提前准备好不要现场录入。把 stu001 的体温预置成 37.5 度申报完成后立刻能在报表页看到这个班的异常数变化这样演示节奏最快也能展示申报到统计的完整闭环。如果你同时准备了一份冷门数据例如导出 Excel放在文档最后作为非功能性需求的补充能提升交付物完整度。5.3 答辩前用一条 SQL 验证整体闭环答辩前一天用下面这条 SQL 检查申报和异常表的联动是否正常SELECT dr.user_id, dr.report_date, dr.temperature, ha.status FROM daily_report dr LEFT JOIN health_abnormal ha ON dr.user_id ha.user_id AND dr.report_date ha.report_date WHERE dr.report_date 2025-06-10 AND dr.is_abnormal 1;如果 is_abnormal 为 1 的行对应 ha.status 为空说明申报逻辑没有正确写入异常表回到事务代码里检查异常插入是否被回滚。这一步通过后再建议把交付包里的数据库脚本重新执行一遍确认打包的 SQL 文件能原样跑通直接替换掉开发目录中的旧脚本即可。保证交付数据库脚本与源码运行结果一致是整套课设验收最常被检查却最容易被忽略的一个环节。本文还有配套的精品资源点击获取 师生健康信息管理系统课设全解析：从数据库设计到源码实现
简介师生健康信息管理系统是一款面向高校的完整毕业设计项目基于Spring Boot框架开发系统包含管理员与学生两种角色并采用前后台分离的设计模式。后台管理功能覆盖学生管理、教师管理、疫情问卷管理、问卷调查管理、返校信息管理等多个模块前台则支持学生进行健康数据填报、问卷作答与返校申请等操作整体业务流程清晰完整。压缩包内共包含5个文件除源代码压缩包和SQL数据库脚本外还配有万字毕业设计文档、答辩用PPT以及说明文档资源总大小为13.91MB能够满足从代码部署到论文撰写的全流程需求。目前该资源已有32人浏览学习适合正在准备毕业设计或课程设计的高校学生也可供初级Java开发者学习项目结构设计与功能实现参考。通过这份资料读者可以快速掌握一套多角色管理系统的完整搭建过程了解数据库表设计、接口调用、数据统计等核心技术的实际应用。1. 师生健康信息管理系统在校园信息化里到底解决什么问题师生健康信息管理系统是数据库课程设计和软件工程课设里出现频率很高的题目交付物往往写作源码、数据库、万字文档、PPT四个部分。系统的业务线条并不复杂角色却不少系统管理员、校医、辅导员、学生都要在同一套平台里看到各自关心的数据最终目标是把个人健康档案、体检记录、每日健康申报、异常症状处置整合成一条可追踪、可统计的信息链。这类课设最常见的丢分点集中在三处数据库表与外键关系说不清异常数据从申报到处置的状态流转走不通统计报表口径和文档截图对不上。换句话说代码只是实现的前半段后半段是文档、数据库脚本、PPT在讲同一个故事。下面按一套成熟可复现的课设方案展开从业务建模和表结构入手给出核心源码实现再讲统计查询的 SQL 写法最后聊万字文档和 PPT 怎么打包才能过答辩。目标读者是正在做师生健康管理课设的学生以及需要快速搭起同类管理信息系统的开发者。2. 数据库设计先行把健康信息拆成六张核心表2.1 角色权限与业务边界谁在往系统里填数据在做表结构之前先列一遍角色角色定清楚表的归属才不打架。系统管理员的职责是维护班级、账号和权限分配不直接写健康记录校医要处理异常申报并回填处置结果辅导员可以查看本班学生申报率和健康档案但不应修改体检数据学生只提交每日体温、症状维护自己的基础档案。对角色的处理用 sys_user 表中的 user_type 字段区分身份不要为每个角色单独建用户表否则权限校验、登录逻辑和外键关联都要成倍膨胀。权限控制在课设阶段做到菜单级就够登录后根据 user_type 决定前端路由后端接口同样做一次拦截。这里有一个容易在答辩时被追问的点学生只能改自己的档案不能把 user_id 换成别人来绕过限制。前端隐藏按钮不算权限控制真正要做的是在 Service 层拿 session 中的登录用户 ID 和请求参数中的 ID 比对不一致直接拒绝。这条规则会在后面源码实现里体现。2.2 表拆分用户、班级、档案、体检、申报、异常各管一段一个代码量在 800 到 1000 行左右的课设数据库拆六张表足够拆分思路是把主数据和行为数据分开。班级、用户、健康档案属于不太变化的静态数据体检记录、每日健康申报、异常处置属于持续写入的流水数据两者混在一张表里修改健康档案会把历史申报也盖掉数据追溯就无从谈起。表名职责关键外键或约束class_info班级信息含年级和辅导员class_id 主键sys_user管理员、校医、教师、学生共用账号表class_id 外键关联班级health_record个人基础健康档案血型、过敏史、病史user_id 唯一键physical_exam身高、体重、视力、血压等体检记录user_id 外键exam_date 可重复daily_report每日健康申报流水user_id report_date 联合唯一health_abnormal异常症状处置记录user_id 外键status 记录处理进度daily_report 和 health_abnormal 是业务上最需要注意的两张表。每日申报在插入时根据体温和症状决定是否同时写入一条异常记录异常表不单独接收用户提交只由申报逻辑生成。这样报表统计健康异常率时只要在 health_abnormal 上做 group by不需要再到 daily_report 中做二次筛选。2.3 MySQL 建表脚本先跑通 DDL 再谈后续下面是完整的建表 SQLMySQL 5.7 和 8.0 都可以直接执行。数据类型按课设常用方式选把约束写清楚比追求极致容量更重要。CREATE TABLE class_info ( class_id INT PRIMARY KEY AUTO_INCREMENT, class_name VARCHAR(100) NOT NULL, grade VARCHAR(20), head_teacher VARCHAR(50) ); CREATE TABLE sys_user ( user_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(255) NOT NULL, real_name VARCHAR(50) NOT NULL, user_type VARCHAR(10) NOT NULL DEFAULT STUDENT, class_id INT, gender VARCHAR(4), phone VARCHAR(20), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (class_id) REFERENCES class_info(class_id) ); CREATE TABLE health_record ( record_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL UNIQUE, blood_type VARCHAR(10), allergy VARCHAR(500), past_history VARCHAR(500), disabled_flag VARCHAR(4) DEFAULT 否, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES sys_user(user_id) ); -- 每日申报同一人同一天只能有一条记录 CREATE TABLE daily_report ( report_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, report_date DATE NOT NULL, temperature DECIMAL(4,2), symptom VARCHAR(255), is_abnormal CHAR(1) DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_date (user_id, report_date), FOREIGN KEY (user_id) REFERENCES sys_user(user_id) ); -- 异常处置一天可多条保留每次跟进痕迹 CREATE TABLE health_abnormal ( abnormal_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, report_date DATE NOT NULL, symptom VARCHAR(300), temperature DECIMAL(4,2), status VARCHAR(20) DEFAULT 待处理, handle_person VARCHAR(50), handle_time DATETIME, remark VARCHAR(500), FOREIGN KEY (user_id) REFERENCES sys_user(user_id) );这里有两个容易忽略的设计细节。daily_report 的联合唯一键 uk_user_date 保证同一个人同一天只能有一条申报记录重复申报时用 ON DUPLICATE KEY UPDATE 更新原记录即可不会在报表里出现重复行。health_abnormal 不加唯一约束因为同一个人的一次异常可能被校医多次跟进每次跟进都要留下独立记录。初始化数据至少建三个账号管理员、一个校医、一个绑定了班级的学生。密码字段在课设里直接存 MD5 值可以接受但要知道企业项目里应当换成 BCryptINSERT INTO class_info (class_name, grade, head_teacher) VALUES (软件2101班, 大三, 王老师); INSERT INTO sys_user (username, password, real_name, user_type, class_id) VALUES (admin, MD5(123456), 系统管理员, ADMIN, NULL), (doctor01, MD5(123456), 校医李华, DOCTOR, NULL), (stu001, MD5(123456), 张明, STUDENT, 1);执行完建表后用 Navicat 或 MySQL Workbench 导出 ER 图截图。这张截图后面要进万字文档和 PPT 的数据库设计章节与交付包里的 SQL 脚本保持一致答辩时这一张图能回答掉数据库表结构的大部分提问。3. 源码实现健康档案增删改查与异常状态流转3.1 工程分层controller、service、mapper 各自管什么师生健康管理系统源码的常见组织方式是 Spring Boot MyBatis页面部分用 Vue 或 JSP 都能运行。分层原则很固定Controller 只做参数接收和响应封装Service 放健康规则判断Mapper 写 SQL。把业务判断放在 Controller 里是课设中最常见的坏味道一旦异常状态规则变化你不得不在每个接口里改重复逻辑。源码包结构建议分成 entity、mapper、service、controller 四层。entity 放置与表字段对应的实体类mapper 负责单表增删改查service 负责跨表操作比如申报时同时写入 daily_report 和 health_abnormal。下面展示健康档案模块最核心的查询与保存接口。3.2 健康档案的查询与保存接口RestController RequestMapping(/health) public class HealthRecordController { private final HealthRecordMapper recordMapper; public HealthRecordController(HealthRecordMapper recordMapper) { this.recordMapper recordMapper; } // 查询某个用户的健康档案 GetMapping(/record/{userId}) public Result getRecord(PathVariable Integer userId) { HealthRecord record recordMapper.selectByUserId(userId); if (record null) { return Result.error(该用户尚未建立健康档案); } return Result.success(record); } // 新增或更新有记录走更新没有走插入 PostMapping(/record/save) public Result saveRecord(RequestBody HealthRecord record) { Integer userId record.getUserId(); if (userId null) { return Result.error(userId 不能为空); } int cnt recordMapper.countByUserId(userId); if (cnt 0) { recordMapper.updateByUserId(record); return Result.success(档案已更新); } recordMapper.insert(record); return Result.success(档案已创建); } }代码里用 countByUserId 判断是否已有记录而不是先把整条记录查出来再判断原因是只需要统计值时一次 count 查询比加载整行数据开销小很多代码也更直接。updateByUserId 在 XML 里对应UPDATE health_record SET ... WHERE user_id #{userId}这个操作依赖 health_record 表上 user_id 的唯一约束。并发下如果同时提交两条新增请求唯一约束会拦截重复插入此时应该捕获 DuplicateKeyException 后执行 update而不是放开唯一约束否则数据一致性就没了。3.3 每日健康申报体温阈值自动写异常表每日申报是整个系统里业务区分度最高的功能。页面提交 userId、reportDate、temperature、symptom 四个字段后端判定体温大于等于 37.3 度或者症状不为空就自动落一条异常记录到 health_abnormal并把状态设为待处理。对应实现如下Service public class DailyReportService { private final DailyReportMapper reportMapper; private final HealthAbnormalMapper abnormalMapper; Transactional public void submitReport(Integer userId, LocalDate reportDate, BigDecimal temperature, String symptom) { // 健康判定规则体温阈值或症状文本非空 boolean abnormal temperature.compareTo(new BigDecimal(37.3)) 0 || (symptom ! null !symptom.trim().isEmpty()); DailyReport report new DailyReport(); report.setUserId(userId); report.setReportDate(reportDate); report.setTemperature(temperature); report.setSymptom(symptom); report.setIsAbnormal(abnormal ? 1 : 0); reportMapper.insertOrUpdate(report); if (abnormal) { HealthAbnormal abnormalRecord new HealthAbnormal(); abnormalRecord.setUserId(userId); abnormalRecord.setReportDate(reportDate); abnormalRecord.setTemperature(temperature); abnormalRecord.setSymptom(symptom); abnormalRecord.setStatus(待处理); abnormalMapper.insert(abnormalRecord); } } }Transactional 声明开启事务保证申报记录和异常表写入要么同时成功要么同时回滚。insertOrUpdate 对应 MySQL 的 ON DUPLICATE KEY UPDATE必须依赖 daily_report 表上的联合唯一键否则重复提交会变成两条申报记录后续报表做去重就要写额外 SQL。health_abnormal 的状态流转建议用 Service 层常量类维护不要在 Controller 里散落魔法字符串状态字段值含义谁触发待处理系统刚生成校医还没接手申报接口自动写入已处理校医完成健康评估校医更新接口已排除复查后排除疑似情况校医更新接口备注里可写明依据把这三种状态集中定义后续做状态统计的 SQL 时where 条件直接引用常量避免口径分散到多个文件里这也是源码规范里值得写进万字文档的一条。4. 统计查询与报表口径让数据库输出答辩要用的数据4.1 按班级统计申报率一条 SQL 同时算两个率数据库课程设计里的报表题最容易翻车核心原因是多表 join 时记录数膨胀count 出来一堆重复值。下面是按班级统计某日申报率和异常率的 SQL注意使用 COUNT(DISTINCT) 去重SELECT ci.class_id, ci.class_name, COUNT(DISTINCT su.user_id) AS total_students, COUNT(DISTINCT dr.report_id) AS reported_students, ROUND(COUNT(DISTINCT dr.report_id) / NULLIF(COUNT(DISTINCT su.user_id), 0) * 100, 1) AS report_rate, COUNT(DISTINCT ha.abnormal_id) AS abnormal_cnt FROM class_info ci LEFT JOIN sys_user su ON su.class_id ci.class_id AND su.user_type STUDENT LEFT JOIN daily_report dr ON dr.user_id su.user_id AND dr.report_date 2025-06-10 LEFT JOIN health_abnormal ha ON ha.user_id su.user_id AND ha.report_date 2025-06-10 GROUP BY ci.class_id, ci.class_name ORDER BY report_rate DESC;查询执行顺序先拿班级做驱动表关联出全部学生再关联 daily_report连接条件里带上日期确保某一天的申报不会污染其他日期最后关联 health_abnormal同样带日期条件拿到当天异常数。NULLIF 把 zero 转成 NULL避免除数不能为零的报错。报表页面展示时report_rate 和 abnormal_cnt 这两个字段就是文档和 PPT 里要截的图口径依据就是这条 SQL不要前端自己再算一遍否则前后端结果对不上答辩现场会非常被动。4.2 近30天异常趋势和症状分布趋势图的数据接口不需要前端拼 JSON后端直接返回 SQL 分组结果前端拿到数组后渲染折线即可-- 近30天每日新增异常数量 SELECT report_date, COUNT(*) AS abnormal_increment FROM health_abnormal WHERE report_date DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY report_date ORDER BY report_date; -- 症状类型分布课设级分析直接统计症状字段文本 SELECT symptom, COUNT(*) AS cnt FROM health_abnormal GROUP BY symptom ORDER BY cnt DESC LIMIT 10;对 symptom 做 GROUP BY 会把“发热”“发烧”这类近似文本统计成两个分类。时间充裕就在申报页面做成下拉框固定症状词从源头统一口径时间紧张就保留文本统计在文档里说明这是文本粒度统计。两种做法都能自圆其说但一套交付物里不能出现两套口径。4.3 索引设计给报表查询补上两个组合索引趋势查询在 health_abnormal 上用 report_date 做范围过滤如果表里只有主键索引数据量到几万条时 MySQL 会走全表扫描。常见做法是补两个组合索引ALTER TABLE health_abnormal ADD INDEX idx_abnormal_date_status (report_date, status); ALTER TABLE daily_report ADD INDEX idx_report_date (report_date);idx_abnormal_date_status 覆盖了按日期过滤、按状态过滤、日期加状态组合过滤三个场景。虽然 health_abnormal 写入频率低但报表和答辩统计都依赖这个索引建立后执行计划的 type 会从 ALL 变为 rangeexplain 结果截图放进文档就能作为数据库优化证据。答辩时如果被问“为什么用组合索引而不是两个单列索引”可以说MySQL 8.0 之后虽然引入了索引合并但组合索引在范围查询和排序上的表现更稳定且索引数量更少写入开销也更小。这句话能挡住绝大多数追问。5. 从源码到交付万字文档与 PPT 怎么编排不返工5.1 万字文档先锁定数据库设计和系统测试万字文档不能最后再写最合理的做法是先写数据库设计再写需求分析最后补测试章节。数据库设计写好代码实现就有据可依文档里贴的表结构只要和交付的 SQL 脚本一致答辩时就不会出现“文档里这么说代码却那么写”的情况。文档里三个核心章节和配套产物的对应关系如下文档章节要写的内容配套产物需求分析角色用例图、功能性需求与非功能性需求用例图截图数据库设计概念结构设计、逻辑结构设计、物理设计建表脚本、ER图、索引说明系统测试每个功能模块的测试用例、步骤、结果功能截图、SQL 执行结果测试章节是大部分人容易忽略的部分。用验证 SQL 查出来的数据结果配一张前端页面截图构成一个完整的测试用例。三个用例就够撑起测试章节正常申报、异常申报自动写入、按班级统计报表。5.2 PPT 主线按一条操作链来演示PPT 建议控制在 12 页以内主线按操作链走管理员登录并分配账号、学生提交每日申报、申报流水写入、统计报表展示、校医处理异常、异常状态更新。每次演示都走这条链路每一页 PPT 截图和现场演示页面顺序保持一致不要 ppt 讲页面 A、手却点到页面 B。演示数据要提前准备好不要现场录入。把 stu001 的体温预置成 37.5 度申报完成后立刻能在报表页看到这个班的异常数变化这样演示节奏最快也能展示申报到统计的完整闭环。如果你同时准备了一份冷门数据例如导出 Excel放在文档最后作为非功能性需求的补充能提升交付物完整度。5.3 答辩前用一条 SQL 验证整体闭环答辩前一天用下面这条 SQL 检查申报和异常表的联动是否正常SELECT dr.user_id, dr.report_date, dr.temperature, ha.status FROM daily_report dr LEFT JOIN health_abnormal ha ON dr.user_id ha.user_id AND dr.report_date ha.report_date WHERE dr.report_date 2025-06-10 AND dr.is_abnormal 1;如果 is_abnormal 为 1 的行对应 ha.status 为空说明申报逻辑没有正确写入异常表回到事务代码里检查异常插入是否被回滚。这一步通过后再建议把交付包里的数据库脚本重新执行一遍确认打包的 SQL 文件能原样跑通直接替换掉开发目录中的旧脚本即可。保证交付数据库脚本与源码运行结果一致是整套课设验收最常被检查却最容易被忽略的一个环节。本文还有配套的精品资源点击获取