选校园疫情防控系统作为毕业设计，听起来蛮耳熟，实际做起来却有诸多麻烦。其中最具代表性的教训是，疫苗预约表与用户表忘记关联，致使两套数据各自运行，最终统计接种率时完全愣住，不得已耗费了一整日去重新构建表结构。而这个指南就是将这些所经历的麻烦直接呈现出来，助力你梳理清楚关键环节。
数据库设计是定生死的第一步
要是数据库设计在最开始的时候没有考虑清楚，那么到了后期进行修改的时候，基本上就等同于重新做一遍。就好比以疫苗预约当作例子来说，在预约表当中必须要存储用户的唯一ID，并非仅仅是记录一个名字，如此做才能够借助关联查询迅速计算出哪些人没有进行预约，以及哪些人打了第一针却遗漏了第二针。
核心表起码得涵盖用户表，健康打卡表，行程报备表，疫苗预约表以及异常上报表。用户表需对角色字段予以区分，打卡表要去记录体温与定位，疫苗预约表要和用户表紧密关联绑定，达成一张表可查全全部信息。
后端开发要优先保稳定
论技术选型，Spring Boot 2.7.x相较于3.x更为稳妥，其社区资源丰富，兼容性也经过了验证，碰到问题时更易于搜索到解决方案。数据库选用MySQL 8.0，在建库之际直接指定utf8mb4编码，以此防止用户提交的emoji表情存入后变成乱码。
被用于存储诸如健康码状态这类常有高频访问的数据对象的专用缓存Redis，打卡记录这种涉及关键操作的信息必须直接写入数据库。事务注解需要在服务层妥善进行添加，就像在预约疫苗时，扣减库存以及生成记录这两个操作必须同时达成成功或失败状况，绝对不可以出现库存已然扣减然而用户却未能成功预约上的情形。
-- 1. 学生健康打卡表（高频操作） CREATE TABLE health_report ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id VARCHAR(20) NOT NULL, report_date DATE NOT NULL, temperature DECIMAL(3,1), health_code_color VARCHAR(10), is_abnormal TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_date (student_id, report_date) ); -- 2. 疫苗预约表（事务处理） CREATE TABLE vaccine_appointment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id VARCHAR(20) NOT NULL, vaccine_id BIGINT NOT NULL, appointment_time DATETIME, status TINYINT DEFAULT 1 COMMENT '1待确认 2已预约 3已完成', FOREIGN KEY (student_id) REFERENCES student(student_id) ); -- 3. 行程报备表（关联分析） CREATE TABLE travel_report ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id VARCHAR(20) NOT NULL, destination VARCHAR(200), departure_time DATETIME, return_time DATETIME, transport_type VARCHAR(20), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); 前端页面要适配真实操作场景
-- 查询今日未打卡学生（教师端用） SELECT s.student_id, s.name, s.class_name FROM student s LEFT JOIN health_report hr ON s.student_id = hr.student_id AND hr.report_date = CURDATE() WHERE hr.id IS NULL AND s.status = 1; -- 统计班级接种率 SELECT class_name, COUNT(*) as total, SUM(CASE WHEN v.status = 3 THEN 1 ELSE 0 END) as vaccinated, CONCAT(ROUND(SUM(CASE WHEN v.status = 3 THEN 1 ELSE 0 END)*100.0/COUNT(*),2),'%') as rate FROM student s LEFT JOIN vaccine_appointment v ON s.student_id = v.student_id GROUP BY class_name; 学生端最为关键之所在乃是一站式服务，需将每日打卡、健康码、行程报备以及疫苗预约放置至首页显著位置，页面应当设计得简洁明晰，打卡选项采用按钮选取方式而非手动进行输入，以此防止学生填错格式。
教师端需着重凸显监控功能，进入页面后能直接瞧见班级打卡率，能看到异常学生列表，还能看到待审批事项。数据展示采用卡片式布局，将未打卡的学生用红色标记出来，把体温异常的学生也用红色标记出来，以此方便辅导员迅速定位问题所在。
管理员端要做实时的数据指挥中心
管理员端并非单纯是信息浏览，它得能够实时瞧见全校防疫态势，首页大屏展露出当日打卡的总人数，未打卡的名单，疫苗覆盖率，以及各院系上报的异常事件数量。
统计报表需能够支持依据学院进行筛选，支持依据年级进行筛选，支持依据时间段进行筛选，像是那种能够导出特定时间段之中毎一日的打卡率变化曲线的情况，又像分析出到底哪个年级的疫苗预约率是最低的这种情形，以此可方便学校开展针对性的通知。
测试必须模拟真实并发和异常场景
进行测试可不是仅仅点点页面便算完成了事。重点在于要测试在高并发状况之下的数据一致性情况。比如说模拟出 10 个学生同时去预约仅剩下 5 份的疫苗名额，在数据库层面需要保证唯有前 5 个人能预约成功，而后 5 个人要明确无误地收到预约失败的提示。
# 关键配置项 spring: datasource: hikari: maximum-pool-size: 50 # 连接池大小 servlet: multipart: max-file-size: 5MB # 图片上传限制 epidemic: warning: abnormal-rate: 0.05 # 异常率超过5%预警 report-rate: 0.90 # 打卡率低于90%预警 网络中断发生在了学生于地下室打卡之际，这迫使对于弱网和断网情形的测试要求被提了出来。同时还要求前端具备本地缓存的能力，在如此信号故障发生以后而导致信息未能正常呈交上去后之断档期内，要确保不会因为信号的问题致使学生被错误地记录为未打卡，而是要在网络恢复之时，可以自动地把数据提交上去。
答辩准备要突出闭环和实战价值
需要在答辩演示的8分钟里，讲明白三级防控体系是怎样进行数据流转的，得从学生打卡开始说起，之后到异常触发教师提醒，然后再到管理员查看全校趋势，每一步都得展现出关联查询的结果。
技术方面的亮点之处是能够提出疫苗预约的防超卖设计，采用数据库乐观锁或者基于 Redis 的分布式锁去切实保证库存数据的准确无误。而像如何应对 1000 人同时打卡这样的常见问题，能够从数据库连接池的配置以及异步写入的角度予以解释、说明。
最后向大家提一个问题，你们于进行毕业设计期间，数据库表结构是预先全部设计就绪后才开展开发工作，还是在编写代码的进程中同步进行调整呢？欢迎于评论区域留言分享自身经验，点赞收藏以便后续进行查阅，同时也别忘了关注从而获取更多实战方面的干货。
