简介：《学生学籍管理系统.doc》面向计算机专业课程设计、数据库课程实践及教务信息化入门学习者，围绕学生基本信息、学籍与成绩数据管理，提供从需求分析到数据库落地的文档化设计参考。压缩包共1个doc文件，约295KB，以单文档形式组织，便于通读、摘录与二次整理。文档已有12957人学习下载，内容覆盖项目背景、四阶段开发计划，以及教师、学生、课程、班级、成绩等管理模块和教务处管理员、学生两类用户的认证与权限划分。数据库部分给出学院、专业、年级、班级、学生、课程、教师等实体关系，含一对多、多对多联系与E-R图说明，并列出学生信息表、课程数据表、选课表、教师任课表等关系模式集，结合SQL Server 2005讨论逻辑结构、物理结构及字段与主键设置，可供课程设计文档撰写和学籍管理数据库原型搭建参考。

1. 从一份 .doc 到能跑起来的库：这个学生学籍管理系统交付了什么

拿到一份只有 .doc 的交付物，多数人的第一反应是往下翻找代码，翻不到就判定它没价值。这份学生学籍管理系统文档值得多看两眼：需求分析、E-R 图、九组关系模式、十一张物理表、三个索引、十个视图、五个存储过程、十三个触发器，末尾还附了一段能在 SQL Server 2005 上逐段执行的建库脚本。它本质上是一份数据库课程设计的完整交付，也是一套可以直接照抄结构的教务库骨架。适合三类人：要交课设但不想套模板的学生、要给小机构搭学籍和成绩库的后端开发、以及想练手视图、存储过程、触发器三件套的人。下面按我实际拆库的顺序走一遍。

2. 需求落到关系模式：七个实体怎么变成十一张表

2.1 只有两类角色，权限却决定了整张账号表长什么样

文档把使用者限定成两种：教务处管理员和学生。管理员进来能增删改查全院数据，学生进来只能看自己那一行。这个粒度很关键，它决定了后面要不要单独造权限表。我的判断是不用：学生查询本人在student表里靠sno一个条件就能过滤掉，管理员则走全表，权限判断放在应用层的一个if role == 'admin'上就够了。真要为这点需求上 RBAC 五张表，属于给自己找事。

问题出在物理设计这一层。需求写得很正经——“用户必须通过认证才能登入系统”“系统能够自动识别用户类型”“给不同用户分配不同权限”，可落地的账号表只有两列：

-- 原文的账号表，只有账号和操作两个字段 create table system( zhanghao char(10) primary key not null, caozuo varchar(20) not null )

这张表撑不起前面那三条需求。没有密码字段，认证无从谈起；没有角色字段，系统认不出进来的是管理员还是学生；没有sno关联，学生登录后不知道该查谁。字段名用拼音zhanghao、caozuo也是一处败笔，后面写 DAO 层时每个字段都得在脑子里翻译一遍，改一次名要动三四个文件。我一般会直接换成下面这个结构，多三列就能把认证、角色、归属全兜住：

-- 改造后的账号表：认证、角色、归属三件事一次说清 create table account( username varchar(32) primary key, -- 登录名 password_hash varchar(128) not null, -- 存哈希，不存明文 role varchar(10) not null, -- 'admin' 或 'student' sno char(10) null, -- 学生账号才有，指向 student.sno status tinyint not null default 1, -- 1 启用 0 停用 constraint ck_role check (role in ('admin','student')), foreign key (sno) references student(sno) )

role上的check约束是我习惯加的，脏数据在入库那一刻就被拦掉，比在业务代码里到处写if省心。sno允许为空，因为管理员账号不挂学生；外键指向student(sno)，意味着学生必须先建档、再开账号，这个顺序在批量导入新生时要留意。

2.2 E-R 里的六组关系，两组多对多是全篇的重点

文档列了七个实体：学院、专业、年级、班级、学生、课程、教师。关系一共六组，其中四组是一对多，两组是多对多。一对多的处理很直接，把“一”那端的主键塞到“多”那端当外键：专业表存学院名、班级表存专业名、学生表存班级名。多对多就必须造中间表，这是关系库里没有捷径的地方。

第一组多对多是学生和课程。文档在这里做了一个我认为很到位的判断：成绩不是学生的属性，也不是课程的属性，而是“这个学生选这门课”这件事的属性，所以score挂在selectcourse上，主键是(sno, cno)的联合主键。这句话看着像常识，但我在实际项目里见过太多把score直接塞进student表的写法，一学期下来学生表宽到几十列，加一门课就要alter table，那才叫真的痛。

第二组多对多是教师和课程，落在teachercourse(cno, teacherID)上，联合主键，表达“这位老师能教这门课”。注意它和selectcourse不是一回事：前者是排课能力，后者是选课结果。selectcourse里另外存了一个teacherID，意思是“这个学生这门课是被哪位老师教的”。这个字段加上之后，主键仍然是(sno, cno)，于是在数据库层面定死了一条规则——一个学生对一门课只能有一条成绩记录。

这条规则在教务场景里迟早要撞墙。学生挂科重修怎么办？覆盖原成绩，历史就没了；想留两次记录，主键直接冲突报 2627。合格的改法是把主键扩成(sno, cno, term)，加一个学期字段，把“一次选课”的粒度从“一门课”细化到“一学期的一门课”。这是二次开发时我第一个会动的地方。

2.3 建表顺序：外键是一条链，顺序错了脚本必然跑不动

这份文档有一处做得比多数课设好：建表语句的排列顺序是对的。college在最前，因为它是所有外键的源头；major紧跟其后引用college；grades和classes再引用这两个；student、course、depart在中间层；teachers要等depart建完；selectcourse和teachercourse在最后，因为它们要引用三张表。

按依赖关系排下来就是一条单链，我把它整理成了下面这张表，照着顺序执行基本不会碰到“引用的对象不存在”这类 1753 错误：

这里有个设计层面的隐患需要提前说清。grades表把grade单独设成了主键，字段类型int，装的是“2024”这种年份数字。主键唯一意味着全校只能有一个 2024 级，可现实里计算机学院的 2024 级和外语学院的 2024 级是两个不同的集合。这条在插入第二条同年级记录时会直接炸，具体现象和改法留到第 5 章细讲。

3. 建库脚本拆解：SQL Server 2005 上的一次完整落地

3.1 建库语句里那几个数字，决定了后面会不会半夜被叫起来

原文的建库脚本不算长，但每个参数都值得抠一遍：

-- 建库：主数据文件 3MB 起步，日志 1MB 起步、上限 2MB、每次涨 10% create database studentmanagesystem on primary( name = 'studentmanagement', -- 逻辑名，和库名不一致 filename = 'D:\DATA\studentmanagesystem.mdf', size = 3, maxsize = unlimited, filegrowth = 1 ) log on( name = 'studentmanagesystem_log', filename = 'D:\DATA\studentmanagesystem_log.ldf', size = 1, maxsize = 2, -- 日志最多 2MB filegrowth = 10% )

size = 3的单位是 MB，filegrowth = 1也是 MB，意思是主数据文件每次不够用就长 1MB。日志那边maxsize = 2是这份脚本里最要命的一笔——日志上限只有 2MB，而 SQL Server 的日志在完整恢复模式下要等事务日志备份才能截断。往selectcourse里批量插几千条成绩，日志写到 2MB 就再也涨不上去，报错 9002“数据库的事务日志已满”。做课设时数据量小，看不出来；一旦拿去做真实数据导入，这个坑一定踩。

还有两处细节：逻辑名studentmanagement和数据库名studentmanagesystem差一个字母，后面做备份还原、写连接串时很容易抓错；filename指向D:\DATA\，这个目录在干净的机器上大概率不存在，create database会直接失败。我在自己机器上跑这套脚本时，习惯先把前两行改成：

-- 稳妥一点的建库参数：目录先建好，日志给足空间 create database studentmanagesystem on primary( name = 'studentmanagesystem', filename = 'D:\DATA\studentmanagesystem.mdf', size = 50MB, filegrowth = 64MB ) log on( name = 'studentmanagesystem_log', filename = 'D:\DATA\studentmanagesystem_log.ldf', size = 32MB, maxsize = 2GB, filegrowth = 64MB )

按固定 MB 增长而不是按百分比增长，是我在数据文件上吃过亏之后养成的习惯。百分比增长在库变大之后一次要扩几百 MB，那一下的写阻塞足够让前端接口超时。日得小库无所谓，但习惯早点养好。

3.2 十一张表里，真正需要细看的是 student 和 selectcourse

物理设计部分给了每张表的字段类型和长度，我挑两张最有代表性的看。

学生表student一共九个字段，主键sno char(10)，学院名、专业名、年级、班级四个外键全部指向维度表：

create table student( sno char(10) primary key not null, -- 学号，定长 10 位 studentname varchar(10) not null, -- 姓名 sex char(2), -- '男'/'女'，char(2) 刚好 sage smallint, -- 年龄 collegename varchar(20), majorname varchar(20), grade int, class char(10), tel varchar(16), foreign key (collegename) references college(collegename), foreign key (majorname) references major(majorname), foreign key (grade) references grades(grade), foreign key (class) references classes(class) )

char(10)装学号是合理的，学号长度固定，定长类型在索引上比varchar更紧凑。studentname varchar(10)只给 10 个字符，遇到四个字的少数民族姓名加上空格就悬了，我一般给到 30。tel varchar(16)装手机号够用，但要留意有人填带区号的座机。四个外键全部指向维度表，这套设计的好处是查询时不用多层 join 就能拿到学院和专业；代价是学院改名要级联更新四张表，而原文并没有配on update cascade。

选课成绩表才是真正承重的一张：

create table selectcourse( sno char(10) not null, cno char(10) not null, teacherID varchar(10), score int, -- 成绩，整数 primary key (sno, cno), -- 一个学生一门课只一条 foreign key (sno) references student(sno), foreign key (cno) references course(cno), foreign key (teacherID) references teachers(teacherID) )

三个外键、一个联合主键，结构没问题。score用int是个可以商量的选择：百分制整数够用，但要做绩点换算、加权平均时，整数会丢精度，我倾向decimal(5,2)。另外score允许为空，这个留白是必要的——选课记录先插入、成绩后录入，空值就代表“还没考”。如果把它设成not null default 0，那就分不清“考了 0 分”和“没考”了，统计及格率时会算错分母。

3.3 索引和视图：三个索引两个都白建，视图里有一半能直接用

原文建了三个索引，全是非聚集索引：

create nonclustered index score_index on selectcourse(score desc); create nonclustered index student_sage_index on student(sage desc); create nonclustered index teachers_sage_index on teachers(sage desc);

后两个索引基本是白建。学生表里按年龄查的场景几乎不存在，教务系统查的是学号、姓名、班级；年龄这种只有几十个不同取值、分布又极度集中的列，选择性太差，优化器八成会直接忽略它走全表扫描。成绩索引稍微有点用，但desc排序在没有top或分页配合时也用不上。真要加索引，我会选这几个方向：student(class)、student(majorname, grade)、selectcourse(cno)——最后这个是因为“查某门课所有成绩”是高频查询，而联合主键(sno, cno)的前缀是sno，按cno单独查走不到索引。

视图部分文档写了十个，按用途可以分三类。第一类是纯投影，比如student_view，就是select * from student，作用是给应用层一个稳定入口，后面表加字段了改视图不用改代码。第二类是跨表拼装，selectcourse_s把选课表和班级视图连起来，让“查某个班所有人的成绩”变成一次单表查询。第三类是分组统计，avg_s算每个学生的平均分：

-- 每个学生的平均成绩，视图列名必须显式给出 create view avg_s(sno, grade, class, gavg) as select sc.sno, cs.grade, cs.class, avg(sc.score) from selectcourse sc join class_s cs on sc.sno = cs.sno group by cs.grade, cs.class, sc.sno

写这类视图有一条硬规则：聚合列必须带别名，或者像上面这样在视图名后面把列清单列全。SQL Server 对视图的每一列都要求有确定的名字，avg(score)这种表达式不给名字，create view会直接失败。原文那一版正好踩了这条，第 5 章会展开。

4. 存储过程与触发器：把业务规则写进数据库

4.1 五个存储过程，覆盖了教务查询的八成场景

文档写了五个存储过程，思路是对的：把高频且固定的多表连接封进数据库，应用层只传参数。第一个scoreproc是最典型的，输入学号，输出该生所有课程的成绩和学分：

-- 按学号查成绩单：三表连接，输入一个参数 create procedure scoreproc @sno char(10) as begin set nocount on; -- 少传一行"影响行数"，省网络往返 select s.sno, s.studentname, c.coursename, sc.score, c.credit from student s join selectcourse sc on s.sno = sc.sno join course c on c.cno = sc.cno where s.sno = @sno; end

调用就是exec scoreproc '2024010101'。这个过程的逻辑很干净：以selectcourse为事实表，两边连维度表，输出结果直接就是一页成绩单。我唯一会加的是set nocount on，它抑制“影响 N 行”的返回消息，批量调用时能省掉不少无谓的网络包。

第二个avgscoreproc用到了输出参数，一次返回平均分和选课人次两个值：

-- 按课程名统计：平均分和选课人次通过 output 参数带回 create procedure avgscoreproc @cname varchar(20), @avg decimal(5,2) output, @count smallint output as begin set nocount on; select @avg = avg(score), @count = count(*) from course c join selectcourse sc on c.cno = sc.cno where c.coursename = @cname; end

输出参数这种写法在 CJK 场景下有个小麻烦：@cname是课程名，可能重复（不同学院开同名课），一旦重复上面这个查询会把两门课的人混在一起算。要严谨就得再加学院参数，或者干脆用课程号当入口。调用侧需要先declare两个变量再接output：

declare @a decimal(5,2), @b smallint; exec avgscoreproc '数据结构', @a output, @b output; select @a as 平均分, @b as 选课人次;

剩下三个过程走的是同一个套路：majorproc按学院统计专业数和专业清单，classproc按“学院+专业+年级+班级”四要素定位一个班并统计人数，teacherproc按教师姓名反查工号、院系、教研室和所教课程。这五个加起来，基本覆盖了教务日常的查询侧。写侧（增删改）文档没封存储过程，全部交给应用层拼 SQL，这在课设里够用，真上线时我至少会把“录入成绩”封成过程，因为它涉及校验、更新、可能触发重算，放在一个事务里更稳。

4.2 触发器分两类：一类做级联同步，一类做非法数据拦截

文档列了十三个触发器，数量看着吓人，按意图其实只有两类。

第一类是级联同步，解决“主表主键改了，子表外键没跟着改”的问题。比如课程被删掉，选课表里指向它的记录就该一起清掉：

-- 课程删除后，级联清掉对应的选课成绩记录 create trigger ctrig_course_delete on course after delete as begin set nocount on; delete sc from selectcourse sc join deleted d on sc.cno = d.cno; -- deleted 是本次删除的旧行 end

这里的关键是deleted和inserted这两张逻辑表。after delete触发器里，deleted装着刚被删掉的行；after update触发器里，deleted是旧值、inserted是新值；after insert里只有inserted。理解这一点，所有触发器都能读懂。上面对course表删除的级联，本质上和on delete cascade外键是一个效果，用触发器实现等于手工重造了数据库自带的功能，不如直接在外键上写on delete cascade省事。

第二类是合法性拦截，比如往选课表插记录时，学号或课程号在库里根本不存在，就该拒掉：

-- 插入前校验学号和课程号是否存在，不存在就回滚 create trigger check_selectcourse_insert on selectcourse instead of insert as begin set nocount on; insert into selectcourse(sno, cno, teacherID, score) select i.sno, i.cno, i.teacherID, i.score from inserted i where exists (select 1 from student s where s.sno = i.sno) and exists (select 1 from course c where c.cno = i.cno); end

这里我用了instead of insert而不是after insert + rollback。区别很实际：after触发器里执行rollback会把整个外层事务一起回滚，如果应用层在一个事务里连着插十条，一条不合法就全没了，报错信息还很难定位；instead of是“替换掉这次插入”，不合法的行静默跳过，合法行正常入库。两条路各有取舍，但instead of的副作用更可控。

4.3 认证与权限该放应用层，别硬塞进数据库

文档把“用户认证”“识别用户类型”“分配不同权限”写在需求里，但物理设计只给了一张两列的system表，存储过程和触发器里也没有任何登录相关的逻辑。这个缺口需要明确补在哪一层。

我的做法是分工：数据库只管“存账号和角色”，认证逻辑（密码校验、会话、超时）全放应用层。理由很实在——数据库里没有安全的密码哈希函数（SQL Server 2005 时代更是如此），在存储过程里做明文比对等于把密码写在日志里；会话状态也没法存在表里，否则每次请求都要查库。

应用层拿到底层连接之后，最小可用的一条链路是这样：

import pyodbc # 连接串里的驱动名按本机实际装的版本改，2016 之后建议用 ODBC Driver 17 conn = pyodbc.connect( "DRIVER={ODBC Driver 17 for SQL Server};" "SERVER=127.0.0.1;DATABASE=studentmanagesystem;" "UID=app_user;PWD=******;" ) cur = conn.cursor() # 调用存储过程，参数用占位符，别拼字符串 cur.execute("EXEC scoreproc ?", "2024010101") for row in cur.fetchall(): print(row)

用?占位符而不是字符串拼接，这一条是我在安全上最在意的习惯。学号这种输入拼接进 SQL 就是注入入口，而存储过程本身并不防注入，防注入的永远是参数化。数据库账号也要单独开一个app_user，只给execute权限和必要的select，别拿sa直接连。原文脚本里所有对象都建在默认架构下，没有做任何权限隔离，这一步在做课设时会被忽略，但它是从“能跑”到“能给别人用”的分界线。

5. 避坑与排查：这份脚本直接照抄会翻车的五个地方

5.1 建库阶段：路径、日志上限和主键设计

现象一：执行create database立刻报错“操作系统错误 3（系统找不到指定的路径）”或“错误 5（拒绝访问）”。

原因有两层。第一层是filename = 'D:\DATA\...'里的目录根本不存在，SQL Server 不会自动创建中间目录。第二层更隐蔽：就算目录建好了，SQL Server 服务是以某个服务账号运行的，那个账号对你手建的D:\DATA未必有写权限，尤其是数据盘挂在别的分区上的时候。

解决就是两步：先用mkdir D:\DATA建目录，再在目录的安全属性里把 SQL Server 服务账号加进去给“完全控制”。懒得折腾就直接把filename改到默认数据目录下，或者干脆省略filename参数，让实例自己决定放哪。

现象二：数据导入到一半报“数据库的事务日志已满（错误 9002）”，事务被强制回滚。

原因在第 3 章说过：日志文件maxsize = 2（MB），而数据库用的是完整恢复模式，日常操作产生的日志不会自动截断。哪怕只是插几千条成绩，日志也能在一个事务里顶到上限。

解决的顺序是：先把maxsize改成unlimited或给到 2GB，再确认恢复模式。课设环境直接改成简单恢复模式最省事：

-- 先解掉日志上限，再切简单恢复模式，日志会自动截断 alter database studentmanagesystem modify file (name = 'studentmanagesystem_log', maxsize = 2GB); alter database studentmanagesystem set recovery simple;

现象三：插第二个学院的 2024 级时，报主键冲突 2627。

原因是grades表把grade int单独做主键，等于宣布“2024”这个值全库只能出现一次。计算机学院 2024 级和外语学院 2024 级，在这个模型里是同一条记录，插不进去。

解决是改联合主键，把年级和专业的组合作为唯一标识：

-- 年级必须和专业绑定，主键改为复合 alter table grades drop constraint PK__grades__... alter table grades add constraint pk_grades primary key (grade, majorname);

改完还要同步调整student和classes的外键，让它们引用这个复合主键，这一步不能漏，否则外键对不上新主键会报 1776。

5.2 视图与存储过程：列名错位和参数拼写是重灾区

现象四：创建视图时提示“视图或函数 'avg_s' 未指定列名”，或者视图建成了但查询结果对不上号。

两个具体案例。avg_s的select列表里写了聚合avg(score)却没给别名，视图要求每一列都有确定名字，直接创建失败。c_major_view的情况更隐蔽，视图声明了四个列名(collegename, collegeID, majorname, majorID)，里面的select顺序却是collegeID, college.collegename, majorID, majorname，两边的顺序错位，结果就是collegename这一列里装的是学院编号。查询不报错，数据全是错的，这种 bug 最难查。

解决就是让声明和查询严格对齐，聚合列显式给名字：

-- 列顺序必须和 select 列表一一对应 create view c_major_view(collegename, collegeID, majorname, majorID) as select c.collegename, c.collegeID, m.majorname, m.majorID from college c join major m on m.collegename = c.collegename;

现象五：执行存储过程报“列名 'grade' 无效”或“列名 'collegename' 不明确”，又或者exec classprco提示找不到对象。

第一种是字段名抄串了。avgscoreproc里写的是avg(grade)，可成绩字段在selectcourse表里叫score，grade是student表里的年级，而且那个查询根本没 joinstudent。第二种是两张表都有collegename，majorproc里直接写collegename没加表前缀，优化器不知道取哪张。第三种最冤，过程名建的是classproc，调用写成了classprco，两个字母一换，报“找不到存储过程”。

解决就是把所有列都带上表别名，过程名和参数名建完立刻exec一次验证。还有一处：teacherproc的参数声明写成了@college char(10) outchar，outchar不是合法关键字，应该是output，而且collegename是varchar(20)，接char(10)会截断。

5.3 触发器：表名写错、SET 语法错、自插死循环

现象六：删除课程时触发器报“对象名 'SC' 无效”；修改学号时触发器报set子句语法错误。

原文里delete SC where cno in (...)的SC是教科书 E-R 图里的临时表名，物理设计里实际叫selectcourse，照抄必错。修改学号那个触发器写的是update selectcourse set sno in (select sno from inserted) where ...，set后面只能跟列 = 值，不能跟in，全句语法都不成立。正确写法是：

-- 学号变更后，把选课表里的旧学号刷成新学号 create trigger trg_student_sno_update on student after update as begin set nocount on; if not update(sno) return; -- 只关心学号变化 update sc set sno = i.sno from selectcourse sc join deleted d on sc.sno = d.sno -- 旧学号 join inserted i on i.sno <> d.sno; -- 新学号 end

现象七：往student表插入一行，结果表里多出一条'sno','studentname','sex'...这样的垃圾数据，或者直接报超过最大嵌套层数。

原因是那批insert_student、insert_classes、insert_college触发器写成了“插入后往同一张表再插一次字面量”：

-- 反例：after insert 里往同一张表插固定字符串 create trigger insert_student on student after insert as begin insert into student values('sno','studentname','sex','sage', 'collegename','majorname','grade','class','tel') end

这条语句每插一行就触发一次自己，再插一行，再触发。SQL Server 默认关闭递归触发器，所以不会无限递归，但每次插入都会实打实多出一条全是占位字符串的脏数据，主键冲突之后再疯狂报错。这批触发器没有任何业务价值，正确做法是全部删掉：

drop trigger insert_student; drop trigger insert_classes; drop trigger insert_college;

现象八：同一批插入里有一条学号不存在，结果整批十条全部消失。

这就是after insert + rollback的典型副作用。回滚把外层事务一起带走了，应用层看到的是“什么都没插进去”，排查半天。换成instead of insert加where exists过滤，就只有不合法的那条被跳过，其余正常入库，日志里也看得清是哪条被拦了。

6. 二次开发：把课设骨架改成能上线的东西

这套模型能跑，但从“演示”到“能用”中间还差几层。我按改动优先级列了个清单，从上往下做，每一步都能单独验证：

改主键那两步要连着做，顺序是先drop外键、再drop主键、再add新主键、最后把外键加回去。中间任何一步失败都会让表处于半改状态，所以我一般会把整个过程包在一个事务里：

begin try begin tran; alter table selectcourse drop constraint FK__selectcou__sno__...; alter table selectcourse drop constraint PK__selectco__...; alter table selectcourse add term char(11) not null default '2024-2025-1'; alter table selectcourse add constraint pk_sc primary key (sno, cno, term); alter table selectcourse add constraint fk_sc_sno foreign key (sno) references student(sno); commit tran; end try begin catch rollback tran; throw; end catch

约束名在每台机器上都不一样（SQL Server 自动生成的那种PK__selectco__1A14E395），直接抄文档里的语句迁移到另一台机器就报“约束不存在”。查真实名字用sp_help 'selectcourse'，或者查sys.key_constraints。这一条是我在换机器部署时踩过的，从那以后我写任何改表脚本，约束名都先从系统视图里查出来再拼。

触发器那批建议整体砍掉重来。级联同步的交给外键on delete cascade/on update cascade，数据库自己处理得比触发器稳；合法性校验的改成instead of或者干脆挪到应用层——在服务里先查一次student和course，再决定插不插，逻辑更直观，也方便写单元测试。真要留在数据库里，至少给每个触发器加上set nocount on和if not update(列名) return;的短路判断，前者省网络包，后者能在无关字段更新时避免空跑。

如果打算换数据库，几个点要提前记下：varchar在 MySQL 里要改成utf8mb4，否则中文名会截断；char(10)存的学号在 PostgreSQL 里要用char(10)对应，别混text；自增列原文没有（主键都是业务字段），新增的代理键在 MySQL 用auto_increment、在 PostgreSQL 用generated always as identity；getdate()换成now()或current_timestamp。存储过程那五个，跨库基本要重写，output参数在 MySQL 里叫out，语法差别不小。

验证方法我习惯用“脏数据压测”：造 500 个学生、30 门课、2000 条选课记录，把五个存储过程全跑一遍，再随机删一门课、改一个学号、插一条不存在的课程号，看数据库的反馈是不是和预期一致。这份文档里的脚本按原样跑，上面三个动作分别会触发 2627、语法错误和脏数据插入，改完之后应该变成“正常级联”“学号同步更新”“该行被跳过”。改前改后各跑一次，比看十遍文档都管用。

从那以后我每次接手这种“文档 + SQL 脚本”的交付物，都会先在空库上原样跑一遍，把每个报错记下来，再开始改——照着文档抄一遍再改，比对着文档空想哪里可能有问题快得多，也踏实得多。希望帮到你。

本文还有配套的精品资源，点击获取