简介数据库课程设计——职工考勤管理信息系统完整设计文档面向计算机相关专业学生及需要完成数据库课程设计的人员。文档以企业考勤管理为背景系统阐述从需求分析、概念结构设计到逻辑结构设计、物理结构设计与数据库实施的完整流程覆盖员工信息管理、考勤记录、考勤统计、权限管理、异常处理等功能模块并通过数据流图、功能模块图、系统数据流程图梳理系统结构。资源为单个doc格式文档压缩包大小316KB正文包含局部与整体ER图、关系模式、数据关系图、存储记录结构设计、索引创建、数据库与数据表建立、存储过程和触发器创建等具体内容目录章节划分清晰可作为课程设计报告撰写和数据库方案设计的直接参考。目前已有67人学习下载适合需要完成类似考勤管理系统数据库设计或理解系统化设计流程的读者。1. 数据库课程设计里最容易被低估的题目职工考勤管理信息系统拿到“职工考勤管理信息系统”这个课程设计题目多数人的第一反应是“不就是一张员工表加一张打卡表做几个增删改查页面嘛”。真做完一遍的人会知道这个题目表面是管理信息系统实际考的是你对外键策略、时间状态演算、跨天班次和异常数据的态度——而这些恰恰是答辩时老师最愿意追问的地方。网上流传的“推荐文档”大多只给了一份格式模板能把表结构设计讲明白的很少本文就从一张考勤业务的数据骨架开始把从建表到跑通演示的完整路径拆开讲。适合正在做数据库课程设计的学生以及需要一个可快速落地版本参考的开发者。2. 需求梳理与数据建模先画出考勤业务的数据骨架2.1 考勤系统必须覆盖的四类业务对象员工、部门、班次、打卡记录在做职工考勤管理信息系统之前先别急着打开 Navicat 建表。课程设计的评分标准里数据库设计通常占三到四成而设计的起点是需求分析。考勤业务的核心对象只有四类员工、部门、班次、打卡记录。部门提供组织归属员工是考勤主体班次定义了上下班时间规则打卡记录是每天产生的原始事实。再往后延伸请假、加班、补卡都是围绕这四个对象派生出来的子业务。把对象列出来后要画一张 ER 图再动手建表。很多学生图省事直接建表结果写到后面发现员工和部门之间的关系没表达清楚或者考勤记录里缺少“今天是哪个班次”的信息。ER 图不需要画得多专业只要把实体、属性和关系标注清楚就行。常见做法是员工到部门是多对一员工到考勤记录是一对多班次到考勤记录是一对多。这个环节大约花半小时能省掉后面三天改表结构的时间。需要注意的是考勤记录表里应该保存的是“打卡这个动作发生的时间点”而不是直接保存“迟到”“早退”“正常”这样的判断结果。原始事实和业务判断要分开存这是整个考勤系统设计的核心原则。判断结果可以被程序算出来但原始打卡时间一旦丢失或覆盖后面任何规则调整都会让你痛不欲生。2.2 从 ER 图到表结构五个核心表和三个边界问题一个能支撑课程设计答辩的考勤系统至少要有五张核心表部门表、员工表、班次表、考勤记录表、请假表。加班的场景如果要做再补一张加班申请表。部门表和员工表是主数据班次表是规则数据考勤记录表是事实数据请假表是例外数据。设计表结构时会碰到三个边界问题这三个问题在答辩时被问到的概率极高。第一个是“一个人一天打很多次卡怎么处理”。考勤机不会帮你只留下上班和下班两条记录实际情况是员工可能打了四次、五次甚至漏打一次。处理方案有两种一种是用程序取当天第一条作为上班打卡、最后一条作为下班打卡另一种是在考勤记录表里用 clock_in_time 和 clock_out_time 两个字段服务端把同一天的多次打卡合并成一条记录。课程设计规模下第二种更直观报表也好写。第二个是“跨天班次怎么处理”。夜班晚上十点上班、次日早上六点下班这条记录该算在哪一天很多人的做法是直接取日期字段结果夜班的下班打卡永远对不上。正确做法是引入“名义日期”概念以班次的开始日期作为归属日。这个细节放到第四章详细讲这里先记住结论。第三个是“请假和考勤怎么联动”。请假记录通过员工ID关联到员工在统计出勤时要做一次排除当天有请假记录的不参与迟到早退判断。不要在考勤记录表里加一堆“是否请假”的冗余字段通过员工ID和日期关联查询才是干净的模型。2.3 字段级别的取舍用单一状态字段还是用两个时间字段这是考勤表设计里最常见的纠结考勤记录表到底用 clock_in_time、clock_out_time 两个字段还是用 one_time 一个字段加多条记录再加一个 type 字段区分上班还是下班我一般会选两个时间字段的方案。理由有两点。第一报表查询简单统计每天的上下班时间只需要一行记录如果用多条记录方案每次统计都要做聚合SQL 写起来长答辩时老师还会追问聚合逻辑的边界情况。第二两个时间字段天然对应“上班打卡”和“下班打卡”两个动作缺哪个就是漏卡程序判断非常直接。代价是同一个人打三次卡的时候服务端需要做一次合并或丢弃。常见处理是保留最早的作为上班时间、最晚的作为下班时间中间那次忽略。这个逻辑放在程序里而不是放在数据库里数据库只负责存事实。字段类型的选择也要注意。打卡时间用 DATETIME不要用 VARCHAR否则排序和比较会出问题。状态类字段比如考勤状态用 TINYINT 或者 VARCHAR 加 CHECK 约束都可以但值一定要用英文或数字不要用中文。后面第五章会专门讲为什么状态值别用中文。3. MySQL 建表脚本与索引设计可直接抄的落地版本3.1 建库建表 SQL五张表的完整脚本与字段说明如果你所在学校的课程设计环境是 MySQL 5.7 或 8.0下面这套脚本可以直接拿去用。字符集统一用 utf8mb4排序规则用 utf8mb4_general_ci这是避免中文乱码的第一道保险。CREATE DATABASE IF NOT EXISTS attendance_system DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; USE attendance_system; CREATE TABLE dept ( dept_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 部门ID, dept_name VARCHAR(50) NOT NULL COMMENT 部门名称, manager_id INT NULL COMMENT 部门负责人员工ID ) ENGINEInnoDB COMMENT部门表; CREATE TABLE employee ( emp_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 员工ID, emp_no VARCHAR(20) NOT NULL UNIQUE COMMENT 工号, emp_name VARCHAR(30) NOT NULL COMMENT 姓名, gender TINYINT NOT NULL DEFAULT 1 COMMENT 性别: 1男 2女, dept_id INT NOT NULL COMMENT 所属部门ID, hire_date DATE NOT NULL COMMENT 入职日期, is_active TINYINT NOT NULL DEFAULT 1 COMMENT 在职状态: 1在职 0离职, KEY idx_dept_id (dept_id) ) ENGINEInnoDB COMMENT员工表; CREATE TABLE shift ( shift_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 班次ID, shift_name VARCHAR(30) NOT NULL COMMENT 班次名称, start_time TIME NOT NULL COMMENT 上班时间, end_time TIME NOT NULL COMMENT 下班时间, late_tolerance INT NOT NULL DEFAULT 0 COMMENT 迟到容忍分钟数 ) ENGINEInnoDB COMMENT班次表; CREATE TABLE attendance ( att_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 考勤记录ID, emp_id INT NOT NULL COMMENT 员工ID, work_date DATE NOT NULL COMMENT 名义日期, shift_id INT NOT NULL COMMENT 班次ID, clock_in_time DATETIME NULL COMMENT 上班打卡时间, clock_out_time DATETIME NULL COMMENT 下班打卡时间, att_status TINYINT NOT NULL DEFAULT 0 COMMENT 状态: 0未判定 1正常 2迟到 3早退 4旷工 5漏卡, UNIQUE KEY uk_emp_date (emp_id, work_date), KEY idx_att_status (att_status), KEY idx_shift_id (shift_id) ) ENGINEInnoDB COMMENT考勤记录表; CREATE TABLE leave_record ( leave_id INT PRIMARY KEY AUTO_INCREMENT COMMENT 请假ID, emp_id INT NOT NULL COMMENT 员工ID, leave_date DATE NOT NULL COMMENT 请假日期, leave_type TINYINT NOT NULL COMMENT 类型: 1事假 2病假 3年假, reason VARCHAR(200) NULL COMMENT 请假原因 ) ENGINEInnoDB COMMENT请假记录表;这套脚本里attendance 表是核心。work_date 字段存的是名义日期不是打卡动作实际发生的日期——这一点放在第四章跨天班次里展开。UNIQUE KEY uk_emp_date 约束了员工和日期的唯一性防止同一天产生两条考勤记录。clock_in_time 和 clock_out_time 都允许为 NULLNULL 就代表漏卡这个设计比用默认值‘0000-00-00’干净得多。运行环境上的注意点MySQL 8.0 默认的驱动是 com.mysql.cj.jdbc.Driver不是旧版的 com.mysql.jdbc.Driver。如果你的代码里还在写后者连接会直接报类找不到或驱动版本不兼容。建表前先确认数据库服务端字符集已经是 utf8mb4否则 INSERT 中文时出现 Incorrect string value 错误根源在库的默认配置。3.2 把外键和索引放在刀刃上哪些表加外键、哪些不加课程设计里最常见的翻车操作是给每张表都加上 FOREIGN KEY摆出一副“我很规范”的姿态。结果删除一条部门数据时被员工表的外键约束拦住报错信息又看不懂最后只能手动一条条删。这不是外键的错是使用场景没分清。我建表的原则是开发期和课程设计演示期外键能不加就不加用普通索引加应用层判断来替代。原因很实际——MySQL 的外键约束在删除和更新时会触发额外的检查学生写的删除逻辑往往没有考虑级联策略导致系统里到处是“删除失败”的弹窗。改成普通索引后程序里先查关联记录、再决定是否执行删除逻辑完全可控答辩时还能多讲一句“我在应用层做了关联检查”。但索引要加到位。employee 表的 dept_id 加普通索引因为部门查询员工是高频操作。attendance 表的 emp_id、work_date 加联合唯一索引这是考勤查询最核心的组合条件。leave_record 的 emp_id 和 leave_date 也加索引统计某员工某月考勤时请假排除查询会快很多。索引不是越多越好每张表三到五个就够建多了反而拖慢 INSERT 速度。外键真正适合的场景是底层数据几乎不变、删除靠级联的表关系。比如班次表 shift 被 attendance 引用时如果班次被删会导致历史考勤失去规则依据所以要么用外键禁止删除要么在应用层判断“该班次存在考勤记录时不允许删除”。课程设计阶段应用层判断足够了。3.3 初始化测试数据让系统第一次打开就有东西可看课程设计验收时老师打开系统最怕看到空荡荡的表格页面。空表意味着你的程序可能根本没有正常写入过数据也看不出查询逻辑对不对。正确的做法是准备一份初始化脚本让系统装上就能看到覆盖四类场景的数据正常出勤、迟到、漏卡、请假。INSERT INTO dept (dept_id, dept_name) VALUES (1, 技术部), (2, 人事部); INSERT INTO employee (emp_no, emp_name, gender, dept_id, hire_date) VALUES (E001, 张三, 1, 1, 2022-03-01), (E002, 李四, 2, 2, 2023-01-15); INSERT INTO shift (shift_id, shift_name, start_time, end_time, late_tolerance) VALUES (1, 白班, 09:00:00, 18:00:00, 10), (2, 夜班, 22:00:00, 06:00:00, 10); INSERT INTO attendance (emp_id, work_date, shift_id, clock_in_time, clock_out_time) VALUES (1, 2024-05-06, 1, 2024-05-06 08:55:00, 2024-05-06 18:05:00), (1, 2024-05-07, 1, 2024-05-07 09:20:00, 2024-05-07 18:10:00), (2, 2024-05-06, 1, 2024-05-06 09:02:00, NULL), (2, 2024-05-07, 1, NULL, NULL); INSERT INTO leave_record (emp_id, leave_date, leave_type, reason) VALUES (2, 2024-05-08, 2, 感冒发烧);数据量不用大但场景要全。张三在 5 月 6 日是正常出勤5 月 7 日是迟到李四在 5 月 6 日是下班漏卡5 月 7 日是全天未打卡5 月 8 日请假。这套数据配合第四章的状态判定逻辑程序跑起来后每一条都有对应的业务含义答辩演示时满屏都是可讲的内容。注意插入考勤记录时先不要填 att_status保持默认值 0。状态字段交给程序去更新而不是在 SQL 里手工写死。这样能证明你的系统有真实的判定逻辑而不是拿手工数据充数。4. 考勤业务逻辑实现从打卡记录到出勤状态的演算4.1 为什么不能把“迟到”“正常”直接存成数据库字段有相当一部分课程设计会把 attendance 表设计成直接存“正常”“迟到”“早退”“旷工”这样的文本状态。表面上看起来没问题查询也直观但老师只要追问一句“如果公司把迟到容忍时间从 10 分钟改成 5 分钟你怎么改”你就得把所有历史记录全部 UPDATE 一遍。更麻烦的是如果班次规则本身发生了变化旧数据的判断口径和新数据不一致报表统计就是一笔糊涂账。正确做法是数据库只存打卡的原始时间戳和班次 ID状态由程序在查询或写入时动态计算。这样改迟到容忍时间只需要改班次表里的 late_tolerance 字段历史数据的统计口径自动跟着新规则走。这也是“数据库存事实、程序算结论”这个原则的最典型体现。实现上可以有两个方案。方案一是在每次打卡后立刻调用判定函数把结果写回 att_status 字段好处是查询时不需要现场计算坏处是如果班次规则变了历史状态就失真了需要跑一次批量重算。方案二是不写状态字段每次查询时由后台服务根据打卡时间和班次规则现场计算好处是口径永远一致坏处是查询性能略受影响。课程设计规模下我建议用方案一因为它直观好讲而且可以在系统里做一个“重新计算当月考勤”的按钮来弥补规则变更问题这个按钮本身就是答辩亮点。4.2 状态判定算法迟到、早退、旷工、漏卡的四类判定逻辑下面是一段可以直接拷进后端服务的 Python 判定函数。输入是班次对象和打卡时间输出是状态码。注释里说明了每个分支对应的业务含义。from datetime import datetime, time def judge_attendance(shift, work_date, clock_in, clock_out): 判定单日考勤状态 :param shift: 包含 start_time, end_time, late_tolerance 的班次对象 :param work_date: 名义日期date 类型归属到上班那一天 :param clock_in: 上班打卡时间datetime 或 None :param clock_out: 下班打卡时间datetime 或 None :return: 状态码 int # 全天没有任何打卡旷工 if clock_in is None and clock_out is None: return 4 # 只打了上班卡没有下班卡下班漏卡 if clock_in is not None and clock_out is None: return 5 # 只打了下班卡没有上班卡上班漏卡 if clock_in is None and clock_out is not None: return 5 # 用名义日期班次时间构造标准上下班时间点 # 注意这里要考虑跨天班次end_time 小于 start_time 时加班一天 shift_start datetime.combine(work_date, shift.start_time) if shift.end_time shift.start_time: shift_end datetime.combine(work_date, shift.end_time) else: shift_end datetime.combine(work_date, shift.end_time) timedelta(days1) # 迟到上班打卡时间晚于标准上班时间 容忍分钟数 if clock_in shift_start timedelta(minutesshift.late_tolerance): return 2 # 早退下班打卡时间早于标准下班时间且早退超过10分钟 if clock_out shift_end - timedelta(minutes10): return 3 # 正常 return 1这段逻辑里最关键的参数是 late_tolerance 和早退容差。迟到容忍是班次表里的配置比如白班 9 点上班、容忍 10 分钟那么 9:10 之前打卡都算正常9:10:01 之后就算迟到。早退容差我没有做成表字段直接在代码里写死为 10 分钟——如果你要做得更规范可以像 late_tolerance 一样把早退容忍也加进班次表。一个容易被忽略的坑判断迟到时用的是“上班时间 容忍分钟数”而不是直接用上班时间。如果直接把 9:00 当作判定线员工 9:09 打卡会被判迟到但业务上容忍 10 分钟这就是规则和实现不一致。把容忍逻辑写进程序后班次表调参就能生效这也呼应了前面说的“规则变更不需要改历史数据”。4.3 跨天班次的处理逻辑把日期时间戳归一化成名义日期跨天班次是考勤系统里最容易翻车的地方。夜班 22:00 上班、次日 06:00 下班如果直接按打卡日期的自然日来分组5 月 6 日晚上 22:00 的上班打卡会被归到 5 月 6 日而 5 月 7 日早上 06:00 的下班打卡会被归到 5 月 7 日一条完整的夜班记录被拆成了两天统计全乱。解决办法是引入“名义日期”work_date概念。规则是以班次开始上班的那一天作为该班次的归属日期。夜班 5 月 6 日 22:00 开始那么这条考勤记录的 work_date 就是 5 月 6 日下班打卡时间即便实际发生在 5 月 7 日凌晨依然挂在 5 月 6 日这条记录下。落到代码上就是前面判定函数里的这段逻辑当班次 end_time 小于 start_time 时计算标准下班时间要在名义日期上加一天。这行判断就解决了跨天问题。还有一个前置步骤后台服务在把打卡记录写入考勤表时要判断打卡时间的小时数来判断它属于白班还是夜班。常见做法是如果打卡时间点离某个班次开始时间在 5 小时内就归到该班次否则尝试匹配其他班次。课程设计里班次通常只有两三个这个匹配逻辑用循环就能解决。答辩时如果老师问“夜班的考勤怎么算”你能把名义日期的设计讲清楚这一个小点就能把分数拉开一档。5. 课程设计避坑清单从建表到答辩最容易翻车的六个地方5.1 MySQL 8.0 连接报错时区导致的服务端拒绝连接现象程序启动时抛The server time zone value Öйú±ê׼ʱ¼ä is unrecognized或者干脆连不上数据库。原因MySQL 8.0 默认时区配置和 JDBC 驱动不匹配驱动要求明确指定时区。解决在 JDBC 连接串后面追加serverTimezoneAsia/ShanghaiuseSSLfalse或者在 MySQL 里执行SET GLOBAL time_zone 8:00。对于驱动类名8.0 必须用com.mysql.cj.jdbc.Driver别再抄旧教程里的com.mysql.jdbc.Driver。这个问题一度被很多学生当成玄学实际上是一个参数的事。5.2 中文写入报错 Incorrect string value建库时没定字符集现象INSERT 中文姓名或部门名时报错但英文数据正常。原因数据库或表的默认字符集是 latin1不支持中文。解决建库时用DEFAULT CHARACTER SET utf8mb4连接串里加characterEncodingutf8。注意查看表结构用SHOW CREATE TABLE employee;确认CHARSETutf8mb4再继续。如果表已经建好用ALTER TABLE employee CONVERT TO CHARACTER SET utf8mb4;补救。这里还要提醒一句字段名、表名不要用中文哪怕数据库支持也别用后面写 SQL 时引号、编码问题会把你耗死。5.3 删除部门时外键报错误用外键约束导致删不掉现象删除一条部门记录时提示Cannot delete or update a parent row: a foreign key constraint fails。原因部门表被员工表通过外键引用直接删除违反正则约束。解决常见做法是取消物理外键改用普通索引加应用层逻辑如果坚持用外键删除前先检查员工表里是否存在该部门的在职员工存在则提示“该部门下还有员工无法删除”。课程设计里我更推荐后者因为代码里可以完整展示这个关联检查逻辑答辩时是加分项。5.4 明明打了卡但状态全是旷工日期比较时忽略了跨天现象夜班员工的下班打卡时间在凌晨状态被判定为旷工或漏卡。原因程序直接用自然日分组没有按名义日期归并。解决按照第四章 4.3 的做法work_date 以班次开始时间所在日期为准判定函数里遇到 end_time 小于 start_time 的情况标准下班时间自动加一天。验证方法找到一条夜班记录打印出 shift_start 和 shift_end 两个变量确认结束时间比开始时间晚。5.5 考勤报表统计结果对不上只统计了有打卡记录的人现象报表里出勤人数永远小于员工总数部分员工整月没有记录。原因SQL 查询用内连接从考勤记录表出发没有打卡记录的员工自然不会被查出来。解决统计时应从 employee 表左连接 attendance 表用LEFT JOIN然后再用条件筛选把没有打卡记录的员工归为旷工。这里有一个固定写法先LEFT JOIN再在 SELECT 里用CASE WHEN把无记录的行转成“旷工”状态。5.6 演示时数据库连接池爆掉反复开关连接页面卡死现象系统点击几次查询后开始卡顿最后提示Too many connections。原因代码里每次查询都新建连接用完没有关闭或者连接池配置太小。解决如果用的是 JDBC记得在 finally 里关闭 Connection、Statement、ResultSet。如果用了连接池比如 HikariCP把 maximumPoolSize 设为 10 到 20在课程设计演示环境下完全足够。这个现象在答辩现场很常见因为演示时会反复点击页面连接不释放就是死路一条。这里也算是“数据库连接池”这类配置的一次实际应用理解参数含义比背配置重要。6. 跑通最小可运行的 Flask SQLite 版本答辩前最后的实战演练6.1 一个文件跑起的后端骨架表定义、路由与数据库增删改查如果你的课程设计允许使用 Python 技术栈我强烈推荐用 Flask SQLite 做最小演示版本。SQLite 不需要安装数据库服务端文件在哪程序就在哪答辩现场不会出现 MySQL 连不上的尴尬。下面的代码是一个单文件后端包含了部门查询、员工列表、打卡记录插入和考勤状态重算四个核心功能。import sqlite3 from flask import Flask, request, jsonify from datetime import datetime, date, timedelta app Flask(__name__) DB_PATH attendance.db def get_db(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row return conn def init_db(): conn get_db() conn.executescript( CREATE TABLE IF NOT EXISTS employee ( emp_id INTEGER PRIMARY KEY AUTOINCREMENT, emp_no TEXT NOT NULL UNIQUE, emp_name TEXT NOT NULL, dept_id INTEGER NOT NULL ); CREATE TABLE IF NOT EXISTS attendance ( att_id INTEGER PRIMARY KEY AUTOINCREMENT, emp_id INTEGER NOT NULL, work_date TEXT NOT NULL, clock_in TEXT, clock_out TEXT, att_status INTEGER DEFAULT 0, UNIQUE(emp_id, work_date) ); ) conn.commit() conn.close() app.route(/employee/list) def employee_list(): conn get_db() rows conn.execute(SELECT * FROM employee).fetchall() conn.close() return jsonify([dict(r) for r in rows]) app.route(/attendance/checkin, methods[POST]) def checkin(): data request.get_json() emp_id data[emp_id] now datetime.now() work_date now.date().isoformat() conn get_db() conn.execute( INSERT INTO attendance (emp_id, work_date, clock_in) VALUES (?, ?, ?) ON CONFLICT(emp_id, work_date) DO UPDATE SET clock_in COALESCE(attendance.clock_in, excluded.clock_in) , (emp_id, work_date, now.isoformat())) conn.commit() conn.close() return jsonify({code: 0, msg: 打卡成功}) app.route(/attendance/recalc) def recalc(): conn get_db() rows conn.execute(SELECT * FROM attendance).fetchall() for row in rows: status judge_simple(row[clock_in], row[clock_out]) conn.execute(UPDATE attendance SET att_status? WHERE att_id?, (status, row[att_id])) conn.commit() conn.close() return jsonify({code: 0, msg: 重算完成}) def judge_simple(clock_in, clock_out): # 简化判定假定白班 09:00-18:00迟到线 09:10 if not clock_in: return 4 if not clock_out else 5 if not clock_out: return 5 in_time datetime.fromisoformat(clock_in) if in_time.time() datetime.strptime(09:10:00, %H:%M:%S).time(): return 2 return 1 if __name__ __main__: init_db() app.run(host127.0.0.1, port5000, debugTrue)这个文件的三个路由分别对应课程设计里的三个核心功能查询员工属于数据库增删改查里的 RRetrieve打卡录入是 CCreate重算状态是 UUpdate。SQLite 和 MySQL 的语法差异主要体现在自增主键和 ON CONFLICT 处理上如果你开发时用 MySQL、演示时改用 SQLite上面代码里的表结构和写法可以直接平移。记住课程设计的重点是数据库设计思路和业务逻辑不是数据库服务器的安装配置。6.2 把 SQLite 用于演示的取舍什么可以省略、什么不能省略如果你在开发阶段用的是 MySQL答辩前想转到 SQLite 做演示需要注意三点。第一表结构调整要重新执行因为 SQLite 不支持直接修改列定义你的 five 张核心表要重新 CREATE 一遍。第二SQL 函数有差异比如 MySQL 的 NOW() 在 SQLite 里是 datetime(now, localtime)需要逐一替换。第三外键默认是关闭的SQLite 里要执行PRAGMA foreign_keys ON;才会启用。我的建议是开发环境直接用 SQLite不要切换。它的并发能力足够支撑课程设计演示而且文件型数据库让学生更容易理解数据持久化的概念——关闭程序再打开数据还在。答辩评委如果要看表结构直接连上文件就能查不需要输账号密码。这套方案在“环境装不上导致系统跑不起来”这类翻车场景上能帮你兜住最后的底线。最后说一个我自己的习惯每次交课程设计之前一定会把数据库文件删掉从零跑一遍初始化脚本再手动通过页面做一次打卡、查询、重算的全流程确认换一台电脑也能复现。很多同学开发时一切正常答辩时换了机器、数据库没导入或者密码不对当场黑屏。这类问题和技术水平无关纯粹是交付习惯。如果你照着本文把建表脚本、判定函数和最小后端跑通一遍再自己走一遍全流程这个题目基本就稳了。希望帮到你。本文还有配套的精品资源点击获取