Python+MySQL学生请假系统源码解析：从跑通到进阶改造

简介这份资源是一套面向高校学生与教师的学生请假管理系统源码适合课程设计、毕业设计或教学演示场景帮助解决请假申请、审批与出勤统计的信息化管理问题。压缩包共14个文件以5个Python源码文件为核心配合8个pyc编译文件与1个SQL脚本分别承担业务逻辑、模块编译与数据库建表等用途整体约21KB结构轻量便于快速部署与二次开发。系统覆盖请假申请、多级审批、通知提醒、请假数据统计与角色权限管理等模块并采用前后端分离与RESTful API设计思路便于理解完整业务闭环。目前已有1117人学习下载读者可参考其目录组织与数据库脚本掌握请假流程建模、权限划分及统计分析的实现方式也可作为扩展功能或集成其他教务系统的起点。1. 从一份“能跑起来”的学生请假系统源码说起很多教务信息化项目卡在同一个地方需求不复杂但真要从零写一套能提交、能审批、能查记录的请假流程前端表单、后端接口、数据库表、权限判断一样都少不了。这份请假系统(4)源码包给的就是一个可落地的起点压缩包里能看到 Student.py、qingjia.sql、tech.py、daba.py、Stud.py、vacate.py 这些文件配合pycache目录说明它至少被实际运行过。它解决的是学生提交请假、教师审批、数据落库这条主链路适合课程设计、毕业设计原型或者想拿一套现成 Python MySQL 结构改造成自己学校流程的开发者。下面按“先看懂结构、再跑通、再避坑、最后进阶”的顺序拆一遍。2. 拆解源码结构Student.py、tech.py、vacate.py 各管什么2.1 从文件名反推模块职责拿到一个没有 README 的源码包第一步不是急着运行而是按文件名和依赖关系画出一张职责图。这套请假系统的命名偏拼音加英文混用属于典型的课程设计风格理解成本不高但需要先确认每个文件在流程里的位置。文件推测职责判断依据Student.py学生端主入口或学生实体逻辑命名直指学生角色Stud.py学生数据操作或辅助类与 Student.py 成对出现常见于分层写法tech.py教师端逻辑tech 对应 teacher 简写vacate.py请假业务核心vacate 即请假通常含申请与审批daba.py数据库连接或数据访问封装命名接近 database 缩写qingjia.sql建表与初始数据脚本.sql 后缀导入后才有表结构这里有个血泪经验拼音和英文混用的项目最怕的是同一个概念在不同文件里换了名字。比如“请假”在 vacate.py 里叫 vacate在 qingjia.sql 里叫 qingjia写查询时表名对不上就直接翻车。所以先别改代码先把 qingjia.sql 打开把表名和字段名抄下来后面所有模块都以此为准。2.2 数据库表结构决定业务边界qingjia.sql 是整个系统的地基。常见做法是至少包含用户表、请假记录表两张核心表教师审批动作落在请假记录表的状态字段上。导入前先确认字符集学生姓名和请假事由是中文字符集不对会出现乱码。-- 先建库字符集用 utf8mb4避免中文和特殊符号乱码 CREATE DATABASE qingjia DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE qingjia; -- 用户表区分学生和教师角色 CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, role VARCHAR(10) NOT NULL COMMENT student 或 teacher, real_name VARCHAR(50) ); -- 请假记录表status 是审批流转的核心字段 CREATE TABLE vacate ( id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, reason VARCHAR(255) NOT NULL, days INT NOT NULL, status VARCHAR(20) DEFAULT pending COMMENT pending/approved/rejected, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (student_id) REFERENCES user(id) );上面这段是我按这类系统的通用结构补的参考建表语句实际以 qingjia.sql 里的定义为准。重点看三处role 字段决定登录后进哪个端status 字段决定审批流转create_time 决定统计排序。参数上 days 用 INT 而不是字符串后面做请假天数统计时不用再转换。如果原脚本里 status 用的是数字 0/1/2那就全程用数字别中途混用字符串这是最常见的低级错误。2.3 模块之间的调用链把结构理清后调用链大致是Student.py 或 Stud.py 负责学生登录和提交vacate.py 承接请假业务tech.py 处理教师审批daba.py 统一管数据库连接。运行顺序上先导入 qingjia.sql再改数据库连接配置最后启动主入口。常见做法是把连接信息集中放在 daba.py 里改一处即可如果每个文件都写了一遍连接串那就要逐个检查漏改一个就连不上库。3. 把系统跑起来环境、依赖与启动顺序3.1 环境准备与依赖确认这套源码是 Python 技术栈配套 MySQL。Python 版本建议 3.8 以上MySQL 5.7 或 8.0 都能用。先确认本机有没有装好这两个再动代码。依赖方面课程设计类项目通常只用到标准库加一个数据库驱动常见的是 pymysql 或 mysql-connector。# 查看 Python 版本低于 3.8 建议升级 python --version # 安装 MySQL 驱动二选一即可 pip install pymysql # 或者 pip install mysql-connector-python # 如果代码里用了图形界面可能还需要 pip install tkinter安装完先别急着跑主程序用一行代码测数据库驱动能不能导入能导入说明环境没问题导入报错就是驱动没装对。这一步能省掉后面一半的排查时间。3.2 导入数据库并核对连接参数导入 qingjia.sql 有两种方式命令行和图形工具都行。命令行更直接适合脚本化。# 命令行导入注意 -p 后面直接回车再输密码不要跟密码 mysql -u root -p qingjia.sql # 导入后进库核对表是否建好 mysql -u root -p -e USE qingjia; SHOW TABLES;导入成功后打开 daba.py找到数据库连接部分把 host、user、password、database 四个参数改成自己本机的。参数说明host 本机一般是 127.0.0.1user 默认 rootpassword 是你自己设的database 要和 qingjia.sql 里建的库名一致。这里有个容易忽略的点如果原代码用的是 mysql-connector连接参数名是 database如果用的是 pymysql参数名也是 database但端口写法略有差异按实际驱动调整。3.3 启动顺序与首次登录验证启动顺序建议先确认数据库能连再启动主入口。主入口通常是 Student.py 或 vacate.py看哪个文件里有if __name__ __main__判断。# 典型的启动入口判断找到这个块就知道从哪跑 if __name__ __main__: # 初始化数据库连接 conn get_connection() # 启动主界面或主循环 main()跑起来后先用 qingjia.sql 里预置的账号登录如果没有预置账号就手动往 user 表插一条学生和一条教师记录。验证主链路学生登录提交一条请假教师登录看到这条待审批记录审批通过后学生端状态更新。这条链路通了系统就算跑起来了。如果卡在某一步看控制台报错数据库相关报错九成是连接参数或表字段对不上。4. 避坑与排查跑这套源码最容易翻车的五个地方4.1 中文乱码现象是姓名和事由显示问号现象提交请假后数据库里存的中文变成问号或乱码页面上也显示不正常。原因数据库、表、连接三处字符集不统一常见是建库时用了 latin1或者连接串没指定 charset。解决建库用 utf8mb4连接时显式加 charset 参数。# pymysql 连接时指定字符集 conn pymysql.connect( host127.0.0.1, userroot, passwordyour_password, databaseqingjia, charsetutf8mb4 # 关键不加这行中文大概率乱码 )4.2 表名或字段名对不上现象是 Unknown column现象一提交就报 Unknown column 或 Table doesnt exist。原因代码里写的表名是 vacate数据库里建的是 qingjia或者字段名大小写不一致。解决以 qingjia.sql 为准全局搜索代码里的表名字段名逐个对齐。MySQL 在 Linux 下默认区分大小写Windows 下不区分所以本地能跑不代表服务器能跑这点要提前注意。4.3 驱动没装或装错现象是 ModuleNotFoundError现象启动直接报 ModuleNotFoundError: No module named pymysql。原因依赖没装或者装到了别的 Python 环境里。解决确认当前用的 Python 和 pip 是同一个环境用python -m pip install pymysql装避免 pip 和 python 指向不同版本。4.4 审批状态不流转现象是点了通过没反应现象教师点审批通过学生端状态还是 pending。原因审批动作没写回数据库或者写回了但没提交事务。解决检查审批函数里有没有 commitpymysql 默认不开自动提交漏了 commit 数据不会落库。# 审批更新后必须 commit否则数据不落库 cursor.execute( UPDATE vacate SET status%s WHERE id%s, (approved, vacate_id) ) conn.commit() # 漏了这行审批就等于没做4.5 并发提交重复记录现象是同一学生出现多条相同请假现象网络慢时学生连点提交数据库里出现多条一模一样的请假记录。原因提交按钮没做防重复后端也没做幂等。解决前端提交后禁用按钮后端在插入前先查该学生是否有 pending 状态的相同记录有就拒绝。这是课程设计里最容易被忽略、但答辩时最容易被问到的一点。5. 进阶改造把请假系统从能跑到好用5.1 加一个请假天数统计视图系统能跑之后最有价值的改造是统计分析。教师端想看班级请假率、个人请假次数用一条 SQL 视图就能搞定不用改后端逻辑。-- 按学生统计请假次数和总天数 CREATE VIEW v_vacate_stat AS SELECT u.real_name, COUNT(v.id) AS total_times, IFNULL(SUM(v.days), 0) AS total_days FROM user u LEFT JOIN vacate v ON u.id v.student_id AND v.status approved WHERE u.role student GROUP BY u.id, u.real_name;这个视图的好处是把统计逻辑收在数据库层前端直接查视图就行。参数上注意 LEFT JOIN 保证没请过假的学生也出现在结果里IFNULL 把 NULL 转成 0否则前端显示会出问题。查的时候按 total_days 降序就是请假最多的学生排行。5.2 审批流程从单级扩展到多级原系统大概率是单级审批班主任点一下通过就结束。要扩展成多级核心是给 vacate 表加一个 current_level 字段记录当前审批到第几级再建一张审批记录表存每一级的审批人和意见。改造点原结构改造后状态字段status 单值status current_level审批记录无新增 approve_log 表审批人单一教师按 level 匹配对应角色改造时不要动原有 status 的取值逻辑而是新增字段并行这样旧数据不受影响回滚也方便。我一般会先把 approve_log 表建好再改审批函数每级审批写一条日志最后一级通过才把 status 置为 approved。5.3 验证改造是否成功的检查清单改完之后别凭感觉说“应该没问题”按下面几步走一遍先插一条测试请假走完多级审批查 approve_log 表看是否每级都有记录再查 v_vacate_stat 视图看统计数字对不对最后把 status 手动改回 pending重走一遍确认没有残留数据。这套流程我每次改审批逻辑都强制走一遍因为审批状态机是最容易出玄学问题的地方肉眼看不出来只有数据能说话。从那以后我每次拿到这类课程设计源码都先导入 SQL、对齐字段、跑通主链路再谈改造。这套请假系统(4)源码结构清晰、依赖简单作为学生请假系统的原型足够用改造成本也低。希望帮到你。本文还有配套的精品资源点击获取