简介这份资源是山东科技大学数据库系统概论课程设计的完整实践包面向正在学习数据库基础、需要完成课程设计或上机实验的高校学生。内容围绕数据表的创建与修改展开涵盖字段定义、类型与长度设置、约束条件以及表结构变更等核心知识点并通过编程方式实现相应操作帮助读者把SQL语句与程序逻辑对应起来理解。压缩包共5个文件约197KB包含cpp源代码、可执行程序、编译中间文件、测试数据实例和说明文档分别对应操作实现、直接运行验证、数据测试与设计指导等用途便于对照学习与调试。目前已有682人学习下载。资源还配有测试数据与说明文档可辅助读者验证建表与改表结果、排查执行问题适合作为课程设计参考与数据库入门练习材料。1. 数据库课设救急一套开箱即跑的数据库系统课程设计工程期末周最怕什么不是不会写 SQL是课设要求交一个“能跑起来的数据库系统”而你连从哪张表开始建都还没想清楚。这套数据库系统课程设计资源就是冲着这个场景来的下载解压按说明导入脚本前端界面能点、后端接口能通、增删改查能演示答辩时老师让你现场加一条记录也不至于当场翻车。它适合两类人——一类是数据库系统概论刚学完、需要一份完整参考工程照着跑通的新手另一类是想省下搭架子时间、把精力放在 SQL 优化和事务设计上的熟手。整套东西围绕课程设计常见命题组织表结构、约束、视图、存储过程、前后端交互都有对应实现不是那种只有几张截图没有源码的空壳。2. 工程结构与技术选型从目录看这套数据库系统怎么搭起来拿到压缩包先别急着双击运行花五分钟把目录翻一遍比后面报错再回头找文件省事得多。这套课程设计工程的组织方式比较典型属于“前端页面 后端服务 数据库脚本”三层分离的结构课程设计场景下这种拆法既够用又好讲。2.1 目录骨架与各层职责解压后大致会看到这样几个顶层目录不同版本命名可能略有差异但职责划分是一致的database-course-design/ ├── sql/ # 建库建表、初始化数据、视图与存储过程脚本 │ ├── schema.sql # 表结构、主外键、约束 │ ├── data.sql # 示例数据 │ └── procedure.sql # 存储过程 / 触发器 / 视图 ├── backend/ # 服务端负责连接数据库、暴露接口 │ ├── config/ # 数据库连接配置 │ ├── dao/ # 数据访问层SQL 集中在这里 │ ├── service/ # 业务逻辑 │ └── controller/ # 接口入口 ├── frontend/ # 页面负责表单与列表展示 └── README.md # 环境要求与启动步骤这个分层不是摆设。dao层把 SQL 收拢在一起答辩时老师问“你的查询写在哪”你能直接翻到一个文件service层放业务判断比如借阅数量上限、库存扣减controller只做参数接收和结果返回。常见做法是把数据库连接串单独放config里改环境只动一个文件不用全局搜索。2.2 技术栈与选型理由课程设计对技术栈的要求通常是“能演示、能讲清、别太重”。这套工程一般走的是后端 关系型数据库 简单前端的组合数据库侧用 MySQL 或同类关系库居多因为课程设计命题基本围绕关系模型、范式、事务、视图这些概念展开用关系库才对得上教材。后端语言常见的是 Java配合 JDBC 或轻量框架或 PythonFlask/FastAPI 配数据库驱动前端则是原生 HTML JS 或者一个轻量模板。选型逻辑很直接课程设计答辩要讲清楚“一条请求怎么落到数据库”链路越短越好讲。如果后端套了太重的东西反而说不清数据流。提示先看README.md里写的数据库版本和语言版本再决定装什么环境。版本对不上是新手第一个坑比如脚本里用了较新的语法旧版本数据库直接报错。2.3 数据库连接配置怎么改跑起来之前唯一必须改的基本就是数据库连接信息。以常见的配置文件为例找到backend/config下的配置项# backend/config/db_config.py DB_CONFIG { host: 127.0.0.1, # 本机数据库地址 port: 3306, # 默认端口装的时候没改就是这个 user: root, # 换成你自己的账号 password: your_pwd, # 换成你自己的密码 database: course_design, # 要和 schema.sql 里建的库名一致 charset: utf8mb4 # 中文不乱码的关键 }这里每个参数都有讲究。database必须和建库脚本里的库名完全一致差一个字母就是“Unknown database”charset设成utf8mb4而不是utf8是因为课程设计里经常有学生姓名、备注这类字段utf8在某些字符上会出问题。改完配置先别启动服务下一步先把数据库本身建起来。3. 从零跑通建库、导数据、起服务的完整顺序很多人卡在“代码没问题但页面空白”十有八九是数据库没建对或者服务没连上。这一章按真实执行顺序走一遍每一步都给出可抄的命令和判断标准。3.1 建库与导入脚本先登录数据库再按顺序执行脚本。顺序不能乱先结构、再数据、最后存储过程和视图因为视图依赖表数据依赖表结构。# 登录数据库以 MySQL 为例 mysql -u root -p # 在数据库命令行里依次执行 source /path/to/sql/schema.sql; source /path/to/sql/data.sql; source /path/to/sql/procedure.sql;执行完做一次验证别急着关窗口-- 确认库和表都在 SHOW DATABASES LIKE course_design; USE course_design; SHOW TABLES; -- 抽查一张核心表有没有数据 SELECT COUNT(*) FROM student;如果SHOW TABLES出来的数量比预期少说明schema.sql中途报错了往上翻日志找第一个ERROR通常是外键引用的表还没建、或者字段类型不兼容。procedure.sql报错则多半是权限问题创建存储过程需要相应权限本地 root 账号一般没这个问题。3.2 启动后端服务与接口自测数据库就绪后启动后端。以 Python 后端为例先装依赖再起服务cd backend pip install -r requirements.txt python app.py启动日志里要看到服务监听的端口比如Running on http://127.0.0.1:5000。这时候别直接开浏览器先用命令行打一个接口把“服务通不通”和“数据库通不通”分开验证# 测一个查询接口看返回是不是 JSON 数据 curl http://127.0.0.1:5000/api/students返回一串 JSON 记录说明后端到数据库这条链路是通的返回 500去看后端控制台的异常堆栈大概率是连接配置或 SQL 字段名对不上连接被拒绝说明服务根本没起来回头检查端口占用和依赖安装。3.3 前端页面联调与功能走查后端接口通了再开前端。前端页面通常通过fetch或表单提交调后端接口打开页面后按“列表 → 新增 → 修改 → 删除”的顺序走一遍这是课程设计演示的标准动线。// frontend/js/student.js 里常见的请求写法 fetch(/api/students, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ name: 张三, major: 计算机 }) }) .then(res res.json()) .then(data console.log(新增结果, data));走查时重点看三件事列表能不能刷出数据、新增后列表是否实时更新、删除有没有二次确认。如果新增成功但列表不刷新是前端没重新拉数据如果新增报错但数据库里其实插进去了是后端返回处理有问题。这两类现象要分清不然改错地方。注意演示前把示例数据恢复一遍避免答辩时列表里全是测试时乱填的记录观感很差。4. 核心模块拆解表结构、DAO 层与事务处理的关键实现跑通只是第一步能讲清楚“为什么这么设计”才是课程设计拿分的地方。这一章挑三个最能体现数据库功力的模块拆开看。4.1 表结构与约束设计课程设计的表结构通常围绕一个业务主题展开比如学生选课、图书借阅、库存管理。核心表的字段设计要能体现主键、外键、非空、唯一这些约束这是老师必问的点。-- sql/schema.sql 节选选课关系表 CREATE TABLE course_selection ( id INT PRIMARY KEY AUTO_INCREMENT, -- 代理主键 student_id INT NOT NULL, -- 学生外键 course_id INT NOT NULL, -- 课程外键 select_time DATETIME DEFAULT CURRENT_TIMESTAMP, score DECIMAL(5,2) DEFAULT NULL, -- 成绩允许为空表示未出分 CONSTRAINT fk_student FOREIGN KEY (student_id) REFERENCES student(id), CONSTRAINT fk_course FOREIGN KEY (course_id) REFERENCES course(id), CONSTRAINT uk_student_course UNIQUE (student_id, course_id) -- 防止重复选课 );这段设计里有两个值得在答辩时主动讲的点。一是uk_student_course唯一约束用数据库层面保证“一个学生不能重复选同一门课”比在代码里查一遍再插入更可靠也避免了并发下的重复数据。二是score允许为空语义上区分“没选”和“选了但没出分”如果设成NOT NULL DEFAULT 0统计平均分时就会把未出分的算成 0 分这是常见的设计失误。4.2 DAO 层的 SQL 组织方式数据访问层是把 SQL 和业务代码隔开的地方。好的写法是每个方法只做一件事参数用占位符传杜绝字符串拼接。# backend/dao/selection_dao.py def get_student_courses(conn, student_id): 查询某学生的所有选课记录带课程名 sql SELECT c.name AS course_name, s.score, s.select_time FROM course_selection s JOIN course c ON s.course_id c.id WHERE s.student_id %s ORDER BY s.select_time DESC with conn.cursor() as cur: cur.execute(sql, (student_id,)) # 参数化防注入 return cur.fetchall()这里用%s占位符而不是把student_id拼进字符串是防 SQL 注入的基本功答辩时被问到可以直接答。JOIN把课程名一起查出来避免前端拿到 ID 再发一次请求减少往返。ORDER BY select_time DESC让最新选的课排前面是产品细节但能体现你考虑过使用体验。4.3 事务处理选课扣名额的完整链路事务是数据库课程设计的重头戏最能体现“你懂不懂数据库”。典型场景是选课课程有容量上限选课前要判断余量选课成功要扣减名额这两步必须在一个事务里。# backend/service/selection_service.py def select_course(conn, student_id, course_id): try: conn.begin() # 开启事务 with conn.cursor() as cur: # 加行锁查余量防止并发超选 cur.execute( SELECT capacity, selected FROM course WHERE id %s FOR UPDATE, (course_id,) ) capacity, selected cur.fetchone() if selected capacity: conn.rollback() return {ok: False, msg: 名额已满} # 插入选课记录 cur.execute( INSERT INTO course_selection (student_id, course_id) VALUES (%s, %s), (student_id, course_id) ) # 扣减已选人数 cur.execute( UPDATE course SET selected selected 1 WHERE id %s, (course_id,) ) conn.commit() return {ok: True, msg: 选课成功} except Exception as e: conn.rollback() return {ok: False, msg: str(e)}这段代码的关键在FOR UPDATE。它给课程那一行加排他锁两个学生同时选最后一门课时后一个会等前一个提交后再读到更新后的selected从而正确判断“名额已满”。如果没有这个锁两个请求可能都读到selected capacity - 1都判断有余量结果超选。try/except里任何一步失败都rollback保证“插入记录”和“扣名额”要么都成、要么都不成这就是事务的原子性。答辩时把这段讲透比背十条概念管用。5. 避坑与排查跑这套课程设计最容易翻车的五个地方下面这几条都是实际跑这类工程时反复出现的按“现象 → 原因 → 解决”整理遇到问题先对照排查。5.1 中文乱码现象页面显示的学生姓名、课程名是问号或方块。原因数据库、连接、表三处字符集不一致常见是建库时用了utf8而连接用了utf8mb4或者建表没指定字符集。解决建库语句统一写DEFAULT CHARSETutf8mb4连接配置里charset也设utf8mb4已建的表用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4修正。5.2 外键约束导致导入失败现象执行data.sql时报Cannot add or update a child row。原因示例数据的插入顺序不对子表数据先于父表插入或者引用了不存在的父表 ID。解决确认data.sql里先插student、course再插course_selection如果顺序没问题检查父表 ID 是否被AUTO_INCREMENT改过导致子表引用的 ID 对不上。5.3 端口被占用服务起不来现象启动后端报Address already in use。原因上一次的服务没关干净或者本机别的程序占了同一端口。解决换端口启动或找到占用进程结束掉。Linux/macOS 用lsof -i:5000查Windows 用netstat -ano | findstr 5000查 PID 再结束。5.4 前端请求跨域被拦现象浏览器控制台报CORS policy接口明明能用 curl 通页面就是拿不到数据。原因前端页面和后端服务端口不同浏览器同源策略拦截。解决后端加跨域响应头或在开发阶段用后端直接托管前端静态文件让两者同源。课程设计演示阶段后者更省事。5.5 存储过程创建报权限错误现象执行procedure.sql报Access denied。原因当前数据库账号没有CREATE ROUTINE权限。解决用有权限的账号执行或让管理员授权GRANT CREATE ROUTINE ON course_design.* TO your_userlocalhost;。本地 root 一般不会有这个问题用普通账号才容易踩。6. 二次开发改造把课程设计工程改成你自己的版本这套工程最大的价值不是“交上去能过”而是它给了一个能继续往上加功能的底座。直接照抄容易被看出雷同改造成自己的东西才是正路。我一般按“换业务主题 → 加功能模块 → 补数据库特性”三步走。第一步换主题。把表名和字段按你的命题改比如把“选课”改成“实验室设备借用”course换成equipmentcapacity换成stock业务逻辑基本能平移。改的时候用全局搜索替换但改完一定要重新跑一遍建库脚本因为外键名、约束名里也带着旧表名漏改就报错。第二步加模块。课程设计常见的加分项是“统计报表”和“权限区分”。统计报表可以在 DAO 层加聚合查询比如按院系统计选课人数-- 按院系统计选课人数答辩演示很直观 SELECT s.department, COUNT(cs.id) AS total FROM student s LEFT JOIN course_selection cs ON s.id cs.student_id GROUP BY s.department ORDER BY total DESC;权限区分则是在用户表加role字段登录后按角色过滤菜单和接口。这一步改动面稍大建议先只做“学生只能看自己的记录、管理员能看全部”这一条够用且好讲。第三步补数据库特性。如果原工程只用了基础增删改查可以加一个触发器做审计比如每次成绩修改自动写一条日志到score_log表。触发器是课程设计的高频考点加上去既体现深度又不增加太多代码量。改造方向改动位置难度答辩加分点换业务主题表名、字段、前端文案低体现独立设计加统计报表DAO 层聚合 SQL中展示 SQL 能力加角色权限用户表 接口过滤中体现系统思维加触发器审计数据库脚本低命中课程考点改造完一定要做回归验证把第 3 章的建库、启动、走查流程完整再跑一遍重点测新增和删除因为改表名最容易漏掉的就是这两处的关联逻辑。我吃过一次亏改完表名只测了查询演示时一删记录就报外键错误当场尴尬。从那以后我每次改完表结构都强制把增删改查四条链路各走一遍再收工。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是山东科技大学数据库系统概论课程设计的完整实践包面向正在学习数据库基础、需要完成课程设计或上机实验的高校学生。内容围绕数据表的创建与修改展开涵盖字段定义、类型与长度设置、约束条件以及表结构变更等核心知识点并通过编程方式实现相应操作帮助读者把SQL语句与程序逻辑对应起来理解。压缩包共5个文件约197KB包含cpp源代码、可执行程序、编译中间文件、测试数据实例和说明文档分别对应操作实现、直接运行验证、数据测试与设计指导等用途便于对照学习与调试。目前已有682人学习下载。资源还配有测试数据与说明文档可辅助读者验证建表与改表结果、排查执行问题适合作为课程设计参考与数据库入门练习材料。1. 数据库课设救急一套开箱即跑的数据库系统课程设计工程期末周最怕什么不是不会写 SQL是课设要求交一个“能跑起来的数据库系统”而你连从哪张表开始建都还没想清楚。这套数据库系统课程设计资源就是冲着这个场景来的下载解压按说明导入脚本前端界面能点、后端接口能通、增删改查能演示答辩时老师让你现场加一条记录也不至于当场翻车。它适合两类人——一类是数据库系统概论刚学完、需要一份完整参考工程照着跑通的新手另一类是想省下搭架子时间、把精力放在 SQL 优化和事务设计上的熟手。整套东西围绕课程设计常见命题组织表结构、约束、视图、存储过程、前后端交互都有对应实现不是那种只有几张截图没有源码的空壳。2. 工程结构与技术选型从目录看这套数据库系统怎么搭起来拿到压缩包先别急着双击运行花五分钟把目录翻一遍比后面报错再回头找文件省事得多。这套课程设计工程的组织方式比较典型属于“前端页面 后端服务 数据库脚本”三层分离的结构课程设计场景下这种拆法既够用又好讲。2.1 目录骨架与各层职责解压后大致会看到这样几个顶层目录不同版本命名可能略有差异但职责划分是一致的database-course-design/ ├── sql/ # 建库建表、初始化数据、视图与存储过程脚本 │ ├── schema.sql # 表结构、主外键、约束 │ ├── data.sql # 示例数据 │ └── procedure.sql # 存储过程 / 触发器 / 视图 ├── backend/ # 服务端负责连接数据库、暴露接口 │ ├── config/ # 数据库连接配置 │ ├── dao/ # 数据访问层SQL 集中在这里 │ ├── service/ # 业务逻辑 │ └── controller/ # 接口入口 ├── frontend/ # 页面负责表单与列表展示 └── README.md # 环境要求与启动步骤这个分层不是摆设。dao层把 SQL 收拢在一起答辩时老师问“你的查询写在哪”你能直接翻到一个文件service层放业务判断比如借阅数量上限、库存扣减controller只做参数接收和结果返回。常见做法是把数据库连接串单独放config里改环境只动一个文件不用全局搜索。2.2 技术栈与选型理由课程设计对技术栈的要求通常是“能演示、能讲清、别太重”。这套工程一般走的是后端 关系型数据库 简单前端的组合数据库侧用 MySQL 或同类关系库居多因为课程设计命题基本围绕关系模型、范式、事务、视图这些概念展开用关系库才对得上教材。后端语言常见的是 Java配合 JDBC 或轻量框架或 PythonFlask/FastAPI 配数据库驱动前端则是原生 HTML JS 或者一个轻量模板。选型逻辑很直接课程设计答辩要讲清楚“一条请求怎么落到数据库”链路越短越好讲。如果后端套了太重的东西反而说不清数据流。提示先看README.md里写的数据库版本和语言版本再决定装什么环境。版本对不上是新手第一个坑比如脚本里用了较新的语法旧版本数据库直接报错。2.3 数据库连接配置怎么改跑起来之前唯一必须改的基本就是数据库连接信息。以常见的配置文件为例找到backend/config下的配置项# backend/config/db_config.py DB_CONFIG { host: 127.0.0.1, # 本机数据库地址 port: 3306, # 默认端口装的时候没改就是这个 user: root, # 换成你自己的账号 password: your_pwd, # 换成你自己的密码 database: course_design, # 要和 schema.sql 里建的库名一致 charset: utf8mb4 # 中文不乱码的关键 }这里每个参数都有讲究。database必须和建库脚本里的库名完全一致差一个字母就是“Unknown database”charset设成utf8mb4而不是utf8是因为课程设计里经常有学生姓名、备注这类字段utf8在某些字符上会出问题。改完配置先别启动服务下一步先把数据库本身建起来。3. 从零跑通建库、导数据、起服务的完整顺序很多人卡在“代码没问题但页面空白”十有八九是数据库没建对或者服务没连上。这一章按真实执行顺序走一遍每一步都给出可抄的命令和判断标准。3.1 建库与导入脚本先登录数据库再按顺序执行脚本。顺序不能乱先结构、再数据、最后存储过程和视图因为视图依赖表数据依赖表结构。# 登录数据库以 MySQL 为例 mysql -u root -p # 在数据库命令行里依次执行 source /path/to/sql/schema.sql; source /path/to/sql/data.sql; source /path/to/sql/procedure.sql;执行完做一次验证别急着关窗口-- 确认库和表都在 SHOW DATABASES LIKE course_design; USE course_design; SHOW TABLES; -- 抽查一张核心表有没有数据 SELECT COUNT(*) FROM student;如果SHOW TABLES出来的数量比预期少说明schema.sql中途报错了往上翻日志找第一个ERROR通常是外键引用的表还没建、或者字段类型不兼容。procedure.sql报错则多半是权限问题创建存储过程需要相应权限本地 root 账号一般没这个问题。3.2 启动后端服务与接口自测数据库就绪后启动后端。以 Python 后端为例先装依赖再起服务cd backend pip install -r requirements.txt python app.py启动日志里要看到服务监听的端口比如Running on http://127.0.0.1:5000。这时候别直接开浏览器先用命令行打一个接口把“服务通不通”和“数据库通不通”分开验证# 测一个查询接口看返回是不是 JSON 数据 curl http://127.0.0.1:5000/api/students返回一串 JSON 记录说明后端到数据库这条链路是通的返回 500去看后端控制台的异常堆栈大概率是连接配置或 SQL 字段名对不上连接被拒绝说明服务根本没起来回头检查端口占用和依赖安装。3.3 前端页面联调与功能走查后端接口通了再开前端。前端页面通常通过fetch或表单提交调后端接口打开页面后按“列表 → 新增 → 修改 → 删除”的顺序走一遍这是课程设计演示的标准动线。// frontend/js/student.js 里常见的请求写法 fetch(/api/students, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ name: 张三, major: 计算机 }) }) .then(res res.json()) .then(data console.log(新增结果, data));走查时重点看三件事列表能不能刷出数据、新增后列表是否实时更新、删除有没有二次确认。如果新增成功但列表不刷新是前端没重新拉数据如果新增报错但数据库里其实插进去了是后端返回处理有问题。这两类现象要分清不然改错地方。注意演示前把示例数据恢复一遍避免答辩时列表里全是测试时乱填的记录观感很差。4. 核心模块拆解表结构、DAO 层与事务处理的关键实现跑通只是第一步能讲清楚“为什么这么设计”才是课程设计拿分的地方。这一章挑三个最能体现数据库功力的模块拆开看。4.1 表结构与约束设计课程设计的表结构通常围绕一个业务主题展开比如学生选课、图书借阅、库存管理。核心表的字段设计要能体现主键、外键、非空、唯一这些约束这是老师必问的点。-- sql/schema.sql 节选选课关系表 CREATE TABLE course_selection ( id INT PRIMARY KEY AUTO_INCREMENT, -- 代理主键 student_id INT NOT NULL, -- 学生外键 course_id INT NOT NULL, -- 课程外键 select_time DATETIME DEFAULT CURRENT_TIMESTAMP, score DECIMAL(5,2) DEFAULT NULL, -- 成绩允许为空表示未出分 CONSTRAINT fk_student FOREIGN KEY (student_id) REFERENCES student(id), CONSTRAINT fk_course FOREIGN KEY (course_id) REFERENCES course(id), CONSTRAINT uk_student_course UNIQUE (student_id, course_id) -- 防止重复选课 );这段设计里有两个值得在答辩时主动讲的点。一是uk_student_course唯一约束用数据库层面保证“一个学生不能重复选同一门课”比在代码里查一遍再插入更可靠也避免了并发下的重复数据。二是score允许为空语义上区分“没选”和“选了但没出分”如果设成NOT NULL DEFAULT 0统计平均分时就会把未出分的算成 0 分这是常见的设计失误。4.2 DAO 层的 SQL 组织方式数据访问层是把 SQL 和业务代码隔开的地方。好的写法是每个方法只做一件事参数用占位符传杜绝字符串拼接。# backend/dao/selection_dao.py def get_student_courses(conn, student_id): 查询某学生的所有选课记录带课程名 sql SELECT c.name AS course_name, s.score, s.select_time FROM course_selection s JOIN course c ON s.course_id c.id WHERE s.student_id %s ORDER BY s.select_time DESC with conn.cursor() as cur: cur.execute(sql, (student_id,)) # 参数化防注入 return cur.fetchall()这里用%s占位符而不是把student_id拼进字符串是防 SQL 注入的基本功答辩时被问到可以直接答。JOIN把课程名一起查出来避免前端拿到 ID 再发一次请求减少往返。ORDER BY select_time DESC让最新选的课排前面是产品细节但能体现你考虑过使用体验。4.3 事务处理选课扣名额的完整链路事务是数据库课程设计的重头戏最能体现“你懂不懂数据库”。典型场景是选课课程有容量上限选课前要判断余量选课成功要扣减名额这两步必须在一个事务里。# backend/service/selection_service.py def select_course(conn, student_id, course_id): try: conn.begin() # 开启事务 with conn.cursor() as cur: # 加行锁查余量防止并发超选 cur.execute( SELECT capacity, selected FROM course WHERE id %s FOR UPDATE, (course_id,) ) capacity, selected cur.fetchone() if selected capacity: conn.rollback() return {ok: False, msg: 名额已满} # 插入选课记录 cur.execute( INSERT INTO course_selection (student_id, course_id) VALUES (%s, %s), (student_id, course_id) ) # 扣减已选人数 cur.execute( UPDATE course SET selected selected 1 WHERE id %s, (course_id,) ) conn.commit() return {ok: True, msg: 选课成功} except Exception as e: conn.rollback() return {ok: False, msg: str(e)}这段代码的关键在FOR UPDATE。它给课程那一行加排他锁两个学生同时选最后一门课时后一个会等前一个提交后再读到更新后的selected从而正确判断“名额已满”。如果没有这个锁两个请求可能都读到selected capacity - 1都判断有余量结果超选。try/except里任何一步失败都rollback保证“插入记录”和“扣名额”要么都成、要么都不成这就是事务的原子性。答辩时把这段讲透比背十条概念管用。5. 避坑与排查跑这套课程设计最容易翻车的五个地方下面这几条都是实际跑这类工程时反复出现的按“现象 → 原因 → 解决”整理遇到问题先对照排查。5.1 中文乱码现象页面显示的学生姓名、课程名是问号或方块。原因数据库、连接、表三处字符集不一致常见是建库时用了utf8而连接用了utf8mb4或者建表没指定字符集。解决建库语句统一写DEFAULT CHARSETutf8mb4连接配置里charset也设utf8mb4已建的表用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4修正。5.2 外键约束导致导入失败现象执行data.sql时报Cannot add or update a child row。原因示例数据的插入顺序不对子表数据先于父表插入或者引用了不存在的父表 ID。解决确认data.sql里先插student、course再插course_selection如果顺序没问题检查父表 ID 是否被AUTO_INCREMENT改过导致子表引用的 ID 对不上。5.3 端口被占用服务起不来现象启动后端报Address already in use。原因上一次的服务没关干净或者本机别的程序占了同一端口。解决换端口启动或找到占用进程结束掉。Linux/macOS 用lsof -i:5000查Windows 用netstat -ano | findstr 5000查 PID 再结束。5.4 前端请求跨域被拦现象浏览器控制台报CORS policy接口明明能用 curl 通页面就是拿不到数据。原因前端页面和后端服务端口不同浏览器同源策略拦截。解决后端加跨域响应头或在开发阶段用后端直接托管前端静态文件让两者同源。课程设计演示阶段后者更省事。5.5 存储过程创建报权限错误现象执行procedure.sql报Access denied。原因当前数据库账号没有CREATE ROUTINE权限。解决用有权限的账号执行或让管理员授权GRANT CREATE ROUTINE ON course_design.* TO your_userlocalhost;。本地 root 一般不会有这个问题用普通账号才容易踩。6. 二次开发改造把课程设计工程改成你自己的版本这套工程最大的价值不是“交上去能过”而是它给了一个能继续往上加功能的底座。直接照抄容易被看出雷同改造成自己的东西才是正路。我一般按“换业务主题 → 加功能模块 → 补数据库特性”三步走。第一步换主题。把表名和字段按你的命题改比如把“选课”改成“实验室设备借用”course换成equipmentcapacity换成stock业务逻辑基本能平移。改的时候用全局搜索替换但改完一定要重新跑一遍建库脚本因为外键名、约束名里也带着旧表名漏改就报错。第二步加模块。课程设计常见的加分项是“统计报表”和“权限区分”。统计报表可以在 DAO 层加聚合查询比如按院系统计选课人数-- 按院系统计选课人数答辩演示很直观 SELECT s.department, COUNT(cs.id) AS total FROM student s LEFT JOIN course_selection cs ON s.id cs.student_id GROUP BY s.department ORDER BY total DESC;权限区分则是在用户表加role字段登录后按角色过滤菜单和接口。这一步改动面稍大建议先只做“学生只能看自己的记录、管理员能看全部”这一条够用且好讲。第三步补数据库特性。如果原工程只用了基础增删改查可以加一个触发器做审计比如每次成绩修改自动写一条日志到score_log表。触发器是课程设计的高频考点加上去既体现深度又不增加太多代码量。改造方向改动位置难度答辩加分点换业务主题表名、字段、前端文案低体现独立设计加统计报表DAO 层聚合 SQL中展示 SQL 能力加角色权限用户表 接口过滤中体现系统思维加触发器审计数据库脚本低命中课程考点改造完一定要做回归验证把第 3 章的建库、启动、走查流程完整再跑一遍重点测新增和删除因为改表名最容易漏掉的就是这两处的关联逻辑。我吃过一次亏改完表名只测了查询演示时一删记录就报外键错误当场尴尬。从那以后我每次改完表结构都强制把增删改查四条链路各走一遍再收工。希望帮到你。本文还有配套的精品资源点击获取
