简介这套数据库课程设计以平行志愿模拟录取为核心业务场景面向高校数据库相关课程的学生适合用作课程设计、项目实训或毕业设计的参考实现。项目采用前后端分离结构前端基于Vue生态包含页面组件、路由与样式后端提供Java源码与数据库脚本覆盖考生信息管理、志愿填报、成绩排序与模拟录取等核心流程并体现数据库需求分析、概念模型到物理实现的设计过程。压缩包共969个文件以js、css、scss、vue、ts、java为主另有HTML页面、Markdown说明、SQL脚本、PDF文档及项目配置文件整体大小3.87MB目录结构清晰便于按模块阅读与二次开发。已有104人学习下载。通过学习本系统可直观理解关系表设计、外键约束、多表联查等关键技能也可参照其中的前端交互和后端接口模式快速搭建同类满足课程设计要求的管理系统。 每年高考志愿填报季总有一批计算机相关专业的学生被“数据库课程设计”这门硬课折腾得够呛。手头这个平行志愿模拟录取系统.zip就是很典型的课程设计命题——它不是让你做个简单的增删改查而是要把一套真实的录取规则用数据库和代码落地。解压开以后里面应该包含建表SQL、源码、课程设计报告。这个系统能做什么简单说就是维护考生和院校专业数据按平行志愿规则自动完成模拟投档与录取最后输出录取结果。适合正在做数据库课设、或者想搞懂平行志愿底层逻辑的同学参考。1. 做系统前先吃透平行志愿的三个核心规则1.1 分数优先、遵循志愿、一轮投档这三句话决定表结构我见过太多学生上来就建表结果写到录取逻辑时发现各种别扭只能回头改表结构反复折腾。所以第一件事不是写代码而是把平行志愿的规则嚼碎。平行志愿就三句话分数优先、遵循志愿、一轮投档。分数优先所有考生按总分从高到低排一列同分看位次。遵循志愿轮到某个考生时系统按他填报的A、B、C、D院校志愿依次检索。一轮投档每个考生在整个录取过程中只有一次投档机会。只要投进某一个院校志愿后面的志愿全部失效如果进档后专业没匹配上又不服从调剂被退档了那这一轮也没机会再投其他学校了只能等征集志愿或下一批次。这三句话直接决定了系统主流程的骨架排序、遍历、逐志愿检索、名额判断。你不需要实现复杂的博弈策略核心就是一个“按分数排序 逐个考生逐志愿检查空位”的循环。反过来如果你的表结构不支持按顺序检索志愿后面实现起来会非常痛苦。1.2 系统功能边界怎么划管理员端、考生端、录取引擎做课程设计最忌讳的是功能边界模糊。我的习惯是拿到题目先分模块三个模块就够。管理员端维护考生信息、院校信息、专业招生计划发起模拟录取。考生端填报志愿保存志愿顺序和是否服从调剂查看录取状态。录取引擎系统核心执行上面的“排序 遍历 名额判断”逻辑。很多人在这个环节容易把代码全堆在控制器或界面里点一下按钮就全表扫描。功能边界清楚了代码结构自然就顺了。我在带学生做这套系统时还会特意提醒考生的每个志愿必须包含院校代号、专业意向顺序、是否服从调剂这三个信息缺一个录取引擎就跑不通。2. 数据库选型与表结构设计六张表搞定录取闭环2.1 课程设计选MySQL理由和注意事项我知道很多学校数据库理论课讲的是Oracle甚至SQL Server但课程设计阶段我仍然推荐MySQL。原因很简单环境轻量、解压即用、出问题网上答案最多而且zip包里如果自带建表脚本基本能直接跑。换用其他关系型数据库也不是不行但自增主键写法、limit语法、驱动类名这些细节都会变折腾环境的时间往往比写代码还多。课程设计的评分重点从来不是数据库品牌而是设计规范、逻辑完整性和文档质量。2.2 六张核心表覆盖从录数据到录取结果的完整链路我常用的设计包含六张表学生表、院校表、专业表、招生计划表、志愿表、录取结果表。这六张表刚好覆盖录取闭环。表名核心字段作用studentstudent_id, name, total_score, rank_no保存考生总分与位次collegecollege_id, college_name院校基础信息majormajor_id, college_id, major_name专业信息归属某所院校planid, college_id, major_id, quota院校专业的招生计划人数volunteerid, student_id, order_no, college_id, major_ids, is_adjust考生的院校志愿顺序、专业意向、是否服从调剂admission_resultid, student_id, college_id, major_id, status录取结果status标记投档/录取/退档/未投出这里有两个设计取舍值得多说。第一志愿表里的major_ids我用的是一个逗号分隔的字符串而不是单独拆一张专业志愿子表。课程设计这个数据量用字符串存专业意向解析逻辑简单还能减少一次多表关联查询完全够用也更容易在答辩时讲清楚。第二录取结果表不直接删数据而是用status字段标记状态这样做能保留完整的过程记录老师问“退档的学生有哪些”一条SQL就能查出来。2.3 索引和外键的取舍哪些该建哪些别硬加索引方面student表的total_score应该建索引因为录取引擎第一步就是按总分排序。volunteer表建议在student_id和order_no上建联合索引因为系统高频操作就是查某个考生的志愿列表并且要按order_no排序。数据量几百条时感觉不到差别但课程设计报告里写清索引设计理由就是加分项。外键方面我倾向于逻辑外键而不是物理外键。也就是说表结构保留student_id、college_id这些字段但不加FOREIGN KEY约束。原因很实际造模拟数据和手动调试数据时不用考虑插入顺序不会频繁触发外键冲突。但报告里一定要写明“本设计采用逻辑外键在应用层保证引用完整性”不然容易被老师质疑你的数据完整性意识。3. 从建表SQL到录取引擎完整落地过程3.1 建表脚本与模拟数据引擎、字符集、数据层次感都要注意给你一个可以直接用的建表片段CREATE TABLE student ( student_id VARCHAR(20) PRIMARY KEY, name VARCHAR(50) NOT NULL, total_score DECIMAL(5,2) NOT NULL, rank_no INT NOT NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE volunteer ( id INT AUTO_INCREMENT PRIMARY KEY, student_id VARCHAR(20) NOT NULL, order_no TINYINT NOT NULL, college_id VARCHAR(10) NOT NULL, major_ids VARCHAR(100), is_adjust TINYINT DEFAULT 0, KEY idx_volunteer_student (student_id, order_no), KEY idx_volunteer_college (college_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个细节我专门拎出来说。第一引擎必须用InnoDB。录取过程要保证事务要么全成功要么全回滚MyISAM不支持行级锁和完整事务直接排除。第二字符集用utf8mb4不要用utf8不然遇到生僻字会出问题。第三模拟数据要有层次感。我见过有学生造数据全部是600分排序逻辑根本没效果答辩时被老师一句“你的排序到底起没起作用”问得哑口无言。正确的做法是设几组高分段、中分段、压线分段压线考生能不能投出去正好检验退档逻辑写得对不对。3.2 录取核心代码排序、遍历、名额判断一个不能少录取引擎的核心逻辑我写成了Java伪代码这个结构同时也是最容易给老师讲明白的版本。public void runAdmission() { ListStudent students studentDao.findAll(); students.sort(Comparator .comparing(Student::getTotalScore).reversed() .thenComparing(Student::getRankNo)); for (Student s : students) { ListVolunteer vols volunteerDao.findByStudentId(s.getStudentId()); boolean admitted false; for (Volunteer v : vols) { College c collegeDao.findById(v.getCollegeId()); int used admissionResultDao.countByCollegeId(v.getCollegeId()); if (used c.getPlanCount()) { String majorId matchMajor(v, c); admissionResultDao.insert(s, c, majorId, 已投档); admitted true; break; } } if (!admitted) { admissionResultDao.insert(s, null, null, 未投出); } } }注意三个关键点。第一已录取名额必须从admission_result表实时COUNT出来不能直接读college表的某个字段否则会出现数据不一致。第二matchMajor是退档逻辑的分水岭先遍历专业意向找第一个还有名额的专业如果专业全满再看is_adjust服从调剂就分一个有名额的专业不服从就标记为“退档”。第三每个考生只在最外层循环一次这正好体现“一轮投档”你可以在报告里把这个时间复杂度讲清楚面试时很加分。3.3 事务与连接池两个细节决定系统质量录取过程必须包在事务里。一轮投档意味着这个批次的结果要整体生效如果跑到一半程序崩了前面投出去的记录应该全部回滚。用Spring就直接加Transactional注解放到runAdmission方法上。如果是纯JDBC记得setAutoCommit(false)结束后commit异常时rollback。课程设计阶段我不建议自己模拟并发多线程投档难度高还容易搞出死锁。但如果老师问起来你能说出“InnoDB行锁按固定顺序访问表可以避免死锁”这已经超出一般学生的水平了。连接池也值得写进报告。代码里频繁出现DriverManager.getConnection是很粗糙的写法。用HikariCP或Druid配置几行就能用spring.datasource.hikari.maximum-pool-size10 spring.datasource.hikari.minimum-idle2 spring.datasource.hikari.connection-timeout30000报告里写一句“通过连接池复用数据库连接减少频繁建连开销”这比结尾写十句感想都管用。3.4 解压zip到跑起来环境配置最容易翻车的4个点这个zip包解压以后标准目录结构一般是sql、src、docs、README。想让它顺利跑起来我建议按这个顺序检查环境。数据库版本MySQL 8.x和5.x的驱动类名不一样。MySQL 8.x驱动类是com.mysql.cj.jdbc.DriverMySQL 5.x是com.mysql.jdbc.Driver出现ClassNotFoundException基本都是这个原因。JDK版本Java 8还是Java 11决定了Spring Boot版本和部分语法写法。Maven依赖如果项目用了Maven连不上网会导致依赖拉不下来检查settings.xml镜像配置。数据库字符集如果连接URL里没有characterEncodingutf8插入中文大概率变问号。把这几项按顺序过一遍比盲目跑代码高效得多。我看到太多人卡在环境上最后发现只是驱动名写错而已。4. 常见问题速查与答辩加分技巧4.1 最容易翻车的5个瞬间现象根因解决办法启动报ClassNotFoundException: com.mysql.jdbc.DriverMySQL驱动与数据库版本不匹配换mysql-connector-java 8.x用com.mysql.cj.jdbc.Driver插入中文变成问号连接URL缺少字符集参数追加characterEncodingutf8useSSLfalse志愿表查询顺序乱查询没按order_no排序SQL中ORDER BY student_id, order_no录取后名额不减直接用college表字段计数改为从admission_result表COUNT统计多事务交叉更新导致死锁多个事务访问表的顺序不一致同一事务内按固定顺序访问college、plan等表4.2 老师最爱问的三个问题怎么答问题一你怎么保证“分数优先”答先把全体考生按total_score desc, rank_no asc排序再按这个顺序逐个检索志愿分数高的先处理天然满足分数优先。问题二一轮投档后还有剩余计划怎么办答本批次录取结束剩余计划进入征集志愿阶段不在本系统模拟范围内。这个回答的精髓是敢划边界不要支支吾吾。问题三同分考生怎么处理答按位次rank_no排序。如果题目没给位次可以用语文数学成绩之和做次关键字但必须在设计文档里写清楚。4.3 让系统在验收时眼前一亮的三个细节第一个细节在界面上展示录取进度。模拟录取时后台打印日志当前处理到第几个考生、投档到哪所学校、退档原因是什么。这种过程可视化能极大提升答辩效果因为老师能直观看到系统在工作。第二个细节在课程设计报告里画流程时序。拿一张流程图把录取过程串起来开始、按分数排序、取下一个考生、检索志愿、判断空位、投档或退档。流程图画清楚代码看起来就有很强的逻辑支撑。第三个细节加一个志愿数据校验功能。考生填报时检查院校志愿是否重复、专业志愿是否超出该院校专业列表。把脏数据拦在入口而不是等录取阶段再处理这种“前置校验”的设计意识比多写几个页面更能体现你的数据库设计能力。我个人习惯是在验收前写一份两页纸的设计说明把表结构、索引、事务、录取算法逐项列出理由。这样做最大的好处不是应付答辩而是真正把“数据库设计”这四个字的门道捋清楚了。平行志愿模拟录取系统看起来只是一个课程设计但它背后这套“排队、按序、占坑”的思维在选课系统、排队叫号、资源分配里到处都用得上。做完它你以后再看别的分配型业务系统会觉得都是一回事。本文还有配套的精品资源点击获取