1. 为什么数据库设计是毕设最容易被追问的环节答辩现场有个规律功能演示可以靠提前点好的页面撑过去数据库设计撑不过去。老师只要打开建表脚本翻到 DDLData Definition Language数据定义语言三个问题就够用了学号重复了怎么办、删掉学生以后考勤记录去哪了、这个状态字段里的 0 和 1 分别代表什么。演示证明的是能跑数据库设计证明的是跑得对不对。前者可以排练后者只能靠建表语句自证。很多同学的库里一条约束都没有全靠 Service业务服务层里几个if (exists)兜着。判断只在代码路径上生效换个入口、多一个并发线程、手工改一条数据就绕过去了。这篇只讲一件事哪些规则必须写进 DDL让数据库自己执行。配套源码0 积分下载学生管理系统完整源码 · 含 schema.sql 建表脚本2. 六张表的职责边界表怎么分标准只有一句一张表只回答一个问题。学生表答这个人是谁考勤表答他哪天来过签署表答他签没签。答不了这个问题的字段不该放进来。表名职责关键字段不该装的东西student学生主数据学号、姓名、手机号、分级 ID、归属管理员 ID考勤统计、签署内容admin管理员账号与角色登录名、密码哈希、角色学生名单attendance单次签到事实学生 ID、签到日期、签到时间、状态学生姓名、班级名称level分级字典年级或培养层次层级编码、层级名称具体学生agreement_sign行为守则签署行为学生 ID、守则版本、签署状态、签名图路径守则全文attachment附件元数据业务类型、业务 ID、存储路径、大小文件二进制内容最容易出问题的是attendance。不少同学把姓名、班级名冗余进考勤表理由是查询快、不用 JOIN连接。学生改一次名字历史考勤里就多出查无此人的旧名字。姓名属于student考勤表只留student_id。attachment不该和业务表混在一起。签名图片、导入名单、导出报表共用一张表用业务类型加业务 ID 挂靠加新业务不用改表结构。3. 表关系与主外键设计六张表的关系画成一张图答辩时投影出来比讲十分钟都管用。一个分级包含多名学生一名管理员管理多名学生一名学生多条考勤一名学生多次签署levelstudentadminattendanceagreement_sign图中不含attachment它靠业务 ID 逻辑挂靠没有实线可画。Foreign Key外键永远建在多的那一侧student里放level_id和admin_idattendance里放student_id。反过来在level里存一列学生 ID这一列迟早会变成逗号分隔的字符串然后所有查询都得靠LIKE。索引要跟着查询走。考勤表有两类高频查询查某个学生某月的记录、查某天全班的签到情况。前者需要(student_id, attend_date)后者需要(attend_date, student_id)的 Composite Index复合索引。顺序不能反复合索引只能从最左列开始匹配。一条索引同时伺候两种查询通常两种都不快。attachment是唯一的例外它用业务类型加业务 ID 挂靠无法指向一张确定的表所以不建外键改为写入时校验并对(biz_type, biz_id)建普通索引。4. 唯一约束必须落库先看一个真实的翻车过程。管理员在页面上双击了两次保存两个请求几乎同时进入 Service都执行select count(*)并得到 0都判断不存在都执行insert。结果库里出现两条学号相同的学生。这不是谁写错了代码而是 check-then-act先检查后执行的 Race Condition竞态条件检查和写入之间有时间窗口两个请求都钻了过去。正确的做法是把规则写进 DDL数据定义语言让数据库判重ALTERTABLEstudentADDCONSTRAINTuk_student_noUNIQUE(student_no),ADDCONSTRAINTuk_student_phoneUNIQUE(phone);有了 UNIQUE唯一约束第二个insert会被数据库拒绝抛出 1062 错误。Service 层捕获异常转成学号已存在的提示逻辑反而更短。if (exists)可以留着做友好提示但它是优化不是保障。MySQL 的唯一索引放行多个NULL因为NULL不等于NULL所以手机号可空但不可重复一条索引就够。5. 外键级联策略管理员删除学生考勤记录怎么办这道题答删了就删了会被追问答不知道就结束了。级联策略必须显式声明因为默认值是RESTRICT限制父表有子记录时直接不许删。子表建议策略理由attendanceON DELETE CASCADE考勤依附于学生存在学生没了记录失去主体agreement_signON DELETE RESTRICT签署是凭证不能因为删学生就消失studentlevel_idON DELETE RESTRICT分级字典被引用时不允许删避免学生悬空写法上就是在外键后面补一句CONSTRAINTfk_attendance_studentFOREIGNKEY(student_id)REFERENCESstudent(id)ONDELETECASCADEONUPDATERESTRICT判断只有一条这条记录是事实还是凭证。考勤是事实主体没了事实就没意义签署是凭证价值恰恰在于它曾经发生过所以只能限制删除。更稳妥的做法是给student加deleted_at做 Soft Delete逻辑删除物理删除交给清理脚本。这样删除学生只是标记不可见考勤和签署原样保留。6. 状态字段的三种写法与取舍attendance.status有三种常见写法选哪种直接影响答辩时能不能解释清楚。写法示例优点代价裸数字status tinyint0 正常、1 迟到、2 缺勤省空间随手就写语义只存在于某人脑子里换人接手就失传数字 常量类tinyintAttendanceStatus枚举存储紧凑Java 侧有语义改动集中数据库里看到的仍是数字需要对照代码语义字符串varchar(16)存NORMAL、LATE直接可读导出报表不用翻译占空间拼写错误能写进去裸数字最大的问题不是性能是可维护性。半年后你看status 2也得翻代码才知道是缺勤还是请假。语义字符串最舒服但NORMAL、Normol、normol都能进库因为没有约束拦着。我更推荐第二种再补一层 CHECK检查约束把范围钉死statusTINYINTNOTNULLDEFAULT0CHECK(statusIN(0,1,2,3))这样存储紧凑语义由常量类承载非法值由数据库兜底。如果状态会频繁增加比如以后要加早退“外勤”VARCHAR反而更省事因为改CHECK和改枚举都不便宜。判断标准很简单状态集合稳定就用数字会持续膨胀就用字符串。7. 可运行的建表脚本结构说明schema.sql的顺序有讲究先字典表level、admin再主表student最后事实表attendance、agreement_sign、attachment。外键要求被引用的表先存在反了会直接报错。CREATEDATABASEIFNOTEXISTSstudent_mgmtDEFAULTCHARACTERSETutf8mb4COLLATEutf8mb4_0900_ai_ci;USEstudent_mgmt;CREATETABLEadmin(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,usernameVARCHAR(32)NOTNULL,password_hashVARCHAR(100)NOTNULL,roleTINYINTNOTNULLDEFAULT1,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,CONSTRAINTuk_admin_usernameUNIQUE(username))ENGINEInnoDB;CREATETABLElevel(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,level_codeVARCHAR(16)NOTNULL,level_nameVARCHAR(32)NOTNULL,CONSTRAINTuk_level_codeUNIQUE(level_code))ENGINEInnoDB;CREATETABLEstudent(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,student_noVARCHAR(20)NOTNULL,nameVARCHAR(32)NOTNULL,phoneVARCHAR(20)NULL,level_idBIGINTUNSIGNEDNOTNULL,admin_idBIGINTUNSIGNEDNOTNULL,deleted_atDATETIMENULL,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,CONSTRAINTuk_student_noUNIQUE(student_no),CONSTRAINTuk_student_phoneUNIQUE(phone),CONSTRAINTfk_student_levelFOREIGNKEY(level_id)REFERENCESlevel(id)ONDELETERESTRICT,CONSTRAINTfk_student_adminFOREIGNKEY(admin_id)REFERENCESadmin(id)ONDELETERESTRICT)ENGINEInnoDB;CREATETABLEattendance(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,student_idBIGINTUNSIGNEDNOTNULL,attend_dateDATENOTNULL,checkin_timeDATETIMENULL,statusTINYINTNOTNULLDEFAULT0CHECK(statusIN(0,1,2,3)),CONSTRAINTuk_attendance_student_dateUNIQUE(student_id,attend_date),CONSTRAINTfk_attendance_studentFOREIGNKEY(student_id)REFERENCESstudent(id)ONDELETECASCADE,KEYidx_attend_date_student(attend_date,student_id))ENGINEInnoDB;CREATETABLEagreement_sign(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,student_idBIGINTUNSIGNEDNOTNULL,agreement_versionVARCHAR(16)NOTNULL,sign_statusTINYINTNOTNULLDEFAULT0CHECK(sign_statusIN(0,1)),sign_image_pathVARCHAR(255)NULL,signed_atDATETIMENULL,CONSTRAINTuk_sign_student_versionUNIQUE(student_id,agreement_version),CONSTRAINTfk_sign_studentFOREIGNKEY(student_id)REFERENCESstudent(id)ONDELETERESTRICT)ENGINEInnoDB;CREATETABLEattachment(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,biz_typeVARCHAR(32)NOTNULL,biz_idBIGINTUNSIGNEDNOTNULL,file_pathVARCHAR(255)NOTNULL,file_sizeBIGINTUNSIGNEDNOTNULLDEFAULT0,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,KEYidx_biz(biz_type,biz_id))ENGINEInnoDB;几个细节值得主动讲主键统一BIGINT UNSIGNED自增避免以后改主键类型时间用DATETIME而不是TIMESTAMP后者跟时区转换签到时间被悄悄改掉很难排查字符集用utf8mb4否则生僻字和表情符号写入失败。导入脚本用两行命令就够mysql-uroot-p-eCREATE DATABASE IF NOT EXISTS student_mgmt DEFAULT CHARACTER SET utf8mb4;mysql-uroot-pstudent_mgmtschema.sql8. 答辩时老师最常追问的 5 个数据库问题第一你的表符合 3NFThird Normal Form第三范式吗姓名只在student出现考勤只存student_id没有传递依赖。若追问为什么不做 Denormalization反范式化答数据量小、以写一致性优先。第二索引越多越好吗不是。索引拖慢写入每次insert都要维护索引页复合索引不满足 Leftmost Prefix最左前缀就用不上like %张也会失效。第三Transaction事务用在哪用在多表写入必须同时成功的场景比如新增学生 写签署记录 存签名附件任何一步失败都 Rollback回滚。隔离级别用默认的REPEATABLE READ可重复读即可。第四为什么主键用自增BIGINT而不是学号学号是业务字段可能录错也可能转专业后重编。主键一旦被外键引用改动成本极高。用无意义 ID 做技术主键用唯一索引约束学号。第五互联网公司说不要用外键你为什么用了这是立场题。外键在分库分表和高并发写入时有开销大厂通常下沉到应用层。毕设是单库、数据量小、以正确性优先外键能免费守住完整性。把前提讲清楚比说老师教过好。9. 完整项目与建表脚本获取前面这些设计落到文件里就是一份可直接执行的schema.sql。不想从零对字段可以看这份完整实现。资源标题Spring Boot 3 Vue 3 学生管理系统源码前后端分离 / JWT 鉴权 / 考勤签到 / MySQL毕业设计课程设计可用资源直链https://download.csdn.net/download/2301_79239314/93726588技术栈后端 Java 21、Spring Boot 3.5、Spring Security JWT、Spring Data JPA、MySQL 8、Redis、Knife4j、Spring AOP前端 Vue 3 / Vite / Pinia / Vue Router / Element Plus / Vant / ECharts。资源属性0 积分下载、821 个文件、含schema.sql、配置已脱敏。答辩前先本地导入一遍schema.sql确认六张表和外键都建成功再截图放进 PPT。需要的同学可以到这里取https://download.csdn.net/download/2301_79239314/9372658810. 小结失分点很少是 SQL 写得不够花哨而是规则只写在 Service 层没落进 DDL。学号唯一、手机号唯一、外键归属、级联策略、状态范围这五件事写进建表语句老师翻脚本就能看到你的判断。六张表不算多但边界要清楚主数据、账号、事实、字典、凭证、附件各管一件事。答辩时被问住不可怕答不上来为什么这么设计才可怕。把每条约束背后的理由讲出来比多写十个接口更能说明你懂数据库。标签数据库设计 / 学生管理系统 / 毕业设计 / MySQL / Spring Boot参考资料MySQL 8.4 Reference Manual: FOREIGN KEY Constraints – MySQLMySQL 8.4 Reference Manual: CREATE TABLE and CHECK Constraints – MySQLMySQL 8.4 Reference Manual: Optimization and Indexes – MySQLMySQL 8.4 Reference Manual: Optimizing InnoDB Queries – MySQL大厂 MySQL 建表军规那些评审会上被打回来的坑 – Walter Fan’s BlogMySQL 表结构设计要注意什么 – 阿里云开发者社区Spring Data JPA Reference Documentation – Spring最后更新时间2026-10-21
1. 为什么数据库设计是毕设最容易被追问的环节答辩现场有个规律功能演示可以靠提前点好的页面撑过去数据库设计撑不过去。老师只要打开建表脚本翻到 DDLData Definition Language数据定义语言三个问题就够用了学号重复了怎么办、删掉学生以后考勤记录去哪了、这个状态字段里的 0 和 1 分别代表什么。演示证明的是能跑数据库设计证明的是跑得对不对。前者可以排练后者只能靠建表语句自证。很多同学的库里一条约束都没有全靠 Service业务服务层里几个if (exists)兜着。判断只在代码路径上生效换个入口、多一个并发线程、手工改一条数据就绕过去了。这篇只讲一件事哪些规则必须写进 DDL让数据库自己执行。配套源码0 积分下载学生管理系统完整源码 · 含 schema.sql 建表脚本2. 六张表的职责边界表怎么分标准只有一句一张表只回答一个问题。学生表答这个人是谁考勤表答他哪天来过签署表答他签没签。答不了这个问题的字段不该放进来。表名职责关键字段不该装的东西student学生主数据学号、姓名、手机号、分级 ID、归属管理员 ID考勤统计、签署内容admin管理员账号与角色登录名、密码哈希、角色学生名单attendance单次签到事实学生 ID、签到日期、签到时间、状态学生姓名、班级名称level分级字典年级或培养层次层级编码、层级名称具体学生agreement_sign行为守则签署行为学生 ID、守则版本、签署状态、签名图路径守则全文attachment附件元数据业务类型、业务 ID、存储路径、大小文件二进制内容最容易出问题的是attendance。不少同学把姓名、班级名冗余进考勤表理由是查询快、不用 JOIN连接。学生改一次名字历史考勤里就多出查无此人的旧名字。姓名属于student考勤表只留student_id。attachment不该和业务表混在一起。签名图片、导入名单、导出报表共用一张表用业务类型加业务 ID 挂靠加新业务不用改表结构。3. 表关系与主外键设计六张表的关系画成一张图答辩时投影出来比讲十分钟都管用。一个分级包含多名学生一名管理员管理多名学生一名学生多条考勤一名学生多次签署levelstudentadminattendanceagreement_sign图中不含attachment它靠业务 ID 逻辑挂靠没有实线可画。Foreign Key外键永远建在多的那一侧student里放level_id和admin_idattendance里放student_id。反过来在level里存一列学生 ID这一列迟早会变成逗号分隔的字符串然后所有查询都得靠LIKE。索引要跟着查询走。考勤表有两类高频查询查某个学生某月的记录、查某天全班的签到情况。前者需要(student_id, attend_date)后者需要(attend_date, student_id)的 Composite Index复合索引。顺序不能反复合索引只能从最左列开始匹配。一条索引同时伺候两种查询通常两种都不快。attachment是唯一的例外它用业务类型加业务 ID 挂靠无法指向一张确定的表所以不建外键改为写入时校验并对(biz_type, biz_id)建普通索引。4. 唯一约束必须落库先看一个真实的翻车过程。管理员在页面上双击了两次保存两个请求几乎同时进入 Service都执行select count(*)并得到 0都判断不存在都执行insert。结果库里出现两条学号相同的学生。这不是谁写错了代码而是 check-then-act先检查后执行的 Race Condition竞态条件检查和写入之间有时间窗口两个请求都钻了过去。正确的做法是把规则写进 DDL数据定义语言让数据库判重ALTERTABLEstudentADDCONSTRAINTuk_student_noUNIQUE(student_no),ADDCONSTRAINTuk_student_phoneUNIQUE(phone);有了 UNIQUE唯一约束第二个insert会被数据库拒绝抛出 1062 错误。Service 层捕获异常转成学号已存在的提示逻辑反而更短。if (exists)可以留着做友好提示但它是优化不是保障。MySQL 的唯一索引放行多个NULL因为NULL不等于NULL所以手机号可空但不可重复一条索引就够。5. 外键级联策略管理员删除学生考勤记录怎么办这道题答删了就删了会被追问答不知道就结束了。级联策略必须显式声明因为默认值是RESTRICT限制父表有子记录时直接不许删。子表建议策略理由attendanceON DELETE CASCADE考勤依附于学生存在学生没了记录失去主体agreement_signON DELETE RESTRICT签署是凭证不能因为删学生就消失studentlevel_idON DELETE RESTRICT分级字典被引用时不允许删避免学生悬空写法上就是在外键后面补一句CONSTRAINTfk_attendance_studentFOREIGNKEY(student_id)REFERENCESstudent(id)ONDELETECASCADEONUPDATERESTRICT判断只有一条这条记录是事实还是凭证。考勤是事实主体没了事实就没意义签署是凭证价值恰恰在于它曾经发生过所以只能限制删除。更稳妥的做法是给student加deleted_at做 Soft Delete逻辑删除物理删除交给清理脚本。这样删除学生只是标记不可见考勤和签署原样保留。6. 状态字段的三种写法与取舍attendance.status有三种常见写法选哪种直接影响答辩时能不能解释清楚。写法示例优点代价裸数字status tinyint0 正常、1 迟到、2 缺勤省空间随手就写语义只存在于某人脑子里换人接手就失传数字 常量类tinyintAttendanceStatus枚举存储紧凑Java 侧有语义改动集中数据库里看到的仍是数字需要对照代码语义字符串varchar(16)存NORMAL、LATE直接可读导出报表不用翻译占空间拼写错误能写进去裸数字最大的问题不是性能是可维护性。半年后你看status 2也得翻代码才知道是缺勤还是请假。语义字符串最舒服但NORMAL、Normol、normol都能进库因为没有约束拦着。我更推荐第二种再补一层 CHECK检查约束把范围钉死statusTINYINTNOTNULLDEFAULT0CHECK(statusIN(0,1,2,3))这样存储紧凑语义由常量类承载非法值由数据库兜底。如果状态会频繁增加比如以后要加早退“外勤”VARCHAR反而更省事因为改CHECK和改枚举都不便宜。判断标准很简单状态集合稳定就用数字会持续膨胀就用字符串。7. 可运行的建表脚本结构说明schema.sql的顺序有讲究先字典表level、admin再主表student最后事实表attendance、agreement_sign、attachment。外键要求被引用的表先存在反了会直接报错。CREATEDATABASEIFNOTEXISTSstudent_mgmtDEFAULTCHARACTERSETutf8mb4COLLATEutf8mb4_0900_ai_ci;USEstudent_mgmt;CREATETABLEadmin(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,usernameVARCHAR(32)NOTNULL,password_hashVARCHAR(100)NOTNULL,roleTINYINTNOTNULLDEFAULT1,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,CONSTRAINTuk_admin_usernameUNIQUE(username))ENGINEInnoDB;CREATETABLElevel(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,level_codeVARCHAR(16)NOTNULL,level_nameVARCHAR(32)NOTNULL,CONSTRAINTuk_level_codeUNIQUE(level_code))ENGINEInnoDB;CREATETABLEstudent(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,student_noVARCHAR(20)NOTNULL,nameVARCHAR(32)NOTNULL,phoneVARCHAR(20)NULL,level_idBIGINTUNSIGNEDNOTNULL,admin_idBIGINTUNSIGNEDNOTNULL,deleted_atDATETIMENULL,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,CONSTRAINTuk_student_noUNIQUE(student_no),CONSTRAINTuk_student_phoneUNIQUE(phone),CONSTRAINTfk_student_levelFOREIGNKEY(level_id)REFERENCESlevel(id)ONDELETERESTRICT,CONSTRAINTfk_student_adminFOREIGNKEY(admin_id)REFERENCESadmin(id)ONDELETERESTRICT)ENGINEInnoDB;CREATETABLEattendance(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,student_idBIGINTUNSIGNEDNOTNULL,attend_dateDATENOTNULL,checkin_timeDATETIMENULL,statusTINYINTNOTNULLDEFAULT0CHECK(statusIN(0,1,2,3)),CONSTRAINTuk_attendance_student_dateUNIQUE(student_id,attend_date),CONSTRAINTfk_attendance_studentFOREIGNKEY(student_id)REFERENCESstudent(id)ONDELETECASCADE,KEYidx_attend_date_student(attend_date,student_id))ENGINEInnoDB;CREATETABLEagreement_sign(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,student_idBIGINTUNSIGNEDNOTNULL,agreement_versionVARCHAR(16)NOTNULL,sign_statusTINYINTNOTNULLDEFAULT0CHECK(sign_statusIN(0,1)),sign_image_pathVARCHAR(255)NULL,signed_atDATETIMENULL,CONSTRAINTuk_sign_student_versionUNIQUE(student_id,agreement_version),CONSTRAINTfk_sign_studentFOREIGNKEY(student_id)REFERENCESstudent(id)ONDELETERESTRICT)ENGINEInnoDB;CREATETABLEattachment(idBIGINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,biz_typeVARCHAR(32)NOTNULL,biz_idBIGINTUNSIGNEDNOTNULL,file_pathVARCHAR(255)NOTNULL,file_sizeBIGINTUNSIGNEDNOTNULLDEFAULT0,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,KEYidx_biz(biz_type,biz_id))ENGINEInnoDB;几个细节值得主动讲主键统一BIGINT UNSIGNED自增避免以后改主键类型时间用DATETIME而不是TIMESTAMP后者跟时区转换签到时间被悄悄改掉很难排查字符集用utf8mb4否则生僻字和表情符号写入失败。导入脚本用两行命令就够mysql-uroot-p-eCREATE DATABASE IF NOT EXISTS student_mgmt DEFAULT CHARACTER SET utf8mb4;mysql-uroot-pstudent_mgmtschema.sql8. 答辩时老师最常追问的 5 个数据库问题第一你的表符合 3NFThird Normal Form第三范式吗姓名只在student出现考勤只存student_id没有传递依赖。若追问为什么不做 Denormalization反范式化答数据量小、以写一致性优先。第二索引越多越好吗不是。索引拖慢写入每次insert都要维护索引页复合索引不满足 Leftmost Prefix最左前缀就用不上like %张也会失效。第三Transaction事务用在哪用在多表写入必须同时成功的场景比如新增学生 写签署记录 存签名附件任何一步失败都 Rollback回滚。隔离级别用默认的REPEATABLE READ可重复读即可。第四为什么主键用自增BIGINT而不是学号学号是业务字段可能录错也可能转专业后重编。主键一旦被外键引用改动成本极高。用无意义 ID 做技术主键用唯一索引约束学号。第五互联网公司说不要用外键你为什么用了这是立场题。外键在分库分表和高并发写入时有开销大厂通常下沉到应用层。毕设是单库、数据量小、以正确性优先外键能免费守住完整性。把前提讲清楚比说老师教过好。9. 完整项目与建表脚本获取前面这些设计落到文件里就是一份可直接执行的schema.sql。不想从零对字段可以看这份完整实现。资源标题Spring Boot 3 Vue 3 学生管理系统源码前后端分离 / JWT 鉴权 / 考勤签到 / MySQL毕业设计课程设计可用资源直链https://download.csdn.net/download/2301_79239314/93726588技术栈后端 Java 21、Spring Boot 3.5、Spring Security JWT、Spring Data JPA、MySQL 8、Redis、Knife4j、Spring AOP前端 Vue 3 / Vite / Pinia / Vue Router / Element Plus / Vant / ECharts。资源属性0 积分下载、821 个文件、含schema.sql、配置已脱敏。答辩前先本地导入一遍schema.sql确认六张表和外键都建成功再截图放进 PPT。需要的同学可以到这里取https://download.csdn.net/download/2301_79239314/9372658810. 小结失分点很少是 SQL 写得不够花哨而是规则只写在 Service 层没落进 DDL。学号唯一、手机号唯一、外键归属、级联策略、状态范围这五件事写进建表语句老师翻脚本就能看到你的判断。六张表不算多但边界要清楚主数据、账号、事实、字典、凭证、附件各管一件事。答辩时被问住不可怕答不上来为什么这么设计才可怕。把每条约束背后的理由讲出来比多写十个接口更能说明你懂数据库。标签数据库设计 / 学生管理系统 / 毕业设计 / MySQL / Spring Boot参考资料MySQL 8.4 Reference Manual: FOREIGN KEY Constraints – MySQLMySQL 8.4 Reference Manual: CREATE TABLE and CHECK Constraints – MySQLMySQL 8.4 Reference Manual: Optimization and Indexes – MySQLMySQL 8.4 Reference Manual: Optimizing InnoDB Queries – MySQL大厂 MySQL 建表军规那些评审会上被打回来的坑 – Walter Fan’s BlogMySQL 表结构设计要注意什么 – 阿里云开发者社区Spring Data JPA Reference Documentation – Spring最后更新时间2026-10-21
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
