企业官网建设流程全解析

简介：《学生学籍管理系统.doc》是一份面向教育机构信息化管理场景的学生学籍与成绩管理数据库设计文档，适合计算机专业学生、课程设计或毕业设计开发者，以及需要梳理教务系统建模思路的读者参考。文档围绕学生基本数据、学籍与成绩信息的查询和变更展开，覆盖需求分析、开发计划、概念结构设计、逻辑结构设计、物理结构设计及系统功能实现，并给出学院、专业、年级、班级、学生、课程、教师等实体关系与主要数据表字段说明，同时划分教师、学生、课程、成绩、班级等管理模块及用户认证与权限分配思路。资源包共1个doc文件，约295KB，便于直接查阅和整理成设计文档。已有12957人学习，可作为教务类数据库课程设计、E-R建模、关系模式转换和系统文档撰写的参考资料。

1. 一份只有 .doc 的学生学籍管理系统，值不值得真跑一遍

前阵子有人甩过来一个学生学籍管理系统的课程设计，压缩包里只有一个 .doc，没有一行 Java 或 PHP，通篇是需求分析、E-R 图、字段表格和 SQL 脚本。我第一反应是这东西跑不起来，直到翻到第五部分「实施阶段」——从 create database 开始，九张表、十个视图、五个存储过程、十几个触发器，一条条排下来其实就是一份完整的建库脚本。把它按顺序贴进查询分析器，一个能支撑教务增删改查的数据库就出来了。这份资源适合两类人：数据库课设要交作业、但不知道表该怎么拆的，以及想拿一个结构完整的小型教务库练手 SQL 的。它没有界面，也没有后端代码，价值全在数据模型和那堆存储过程、触发器上，读它是为了看懂一个教务库从需求到落地的完整链路。

2. 需求与概念结构：七个实体怎么从学院-专业-班级这层壳里剥出来

2.1 两类用户、五个模块，先把权限边界画出来

文档开头把使用者分成教务处管理员和学生两类，这个划分决定了后面所有的表设计和查询接口。管理员登录后能进操作界面，做学生、教师、课程、班级、成绩五个模块的增删改查；学生登录后只能进本人信息界面，看自己的学籍和成绩。落到数据层，这两类人共用同一套表，区别只在访问路径——管理员走的是全表操作，学生走的是带 sno 条件的单行查询。所以权限这件事在这个项目里不是靠数据库用户隔离的，而是靠在应用层拼不同的 SQL 实现的，这一点在后面对接后端时必须补上。

五个功能模块对应到表上其实很清晰：学生管理模块动 student，教师管理模块动 teachers，课程管理模块动 course，班级管理模块动 classes，成绩管理模块动 selectcourse。文档里还塞了两个附加描述——学生的院系资料和专业资料、教师的教研室资料，分别落在 college、major、depart 三张字典表上。字典表的增删改查频率远低于业务表，但它们的删除会直接卡住业务表的外键，这是后面建表顺序要特别小心的地方。

原文设计了一张 system 表来存账号：

-- 原始设计：只有账号和操作两个字段 create table system( zhanghao char(10) primary key not null, caozuo varchar(20) not null )

这张表按现在的标准看是残缺的——没有密码字段、没有角色字段、没有状态字段，caozuo这个字段名意图不明，从上下文推断是想记录"这个账号能做哪些操作"，但用 varchar 存一串操作名，既不能索引也没法做权限判断。常见的做法是拆成account(account_id, password_hash, role, ref_id, status)这样的结构，role 取 admin 或 student，ref_id 指向 teachers.teacherID 或 student.sno，登录时先查角色再决定跳哪套查询。这个改造不影响原有九张表，属于二次开发时最容易切入的点。

2.2 七个实体：学院、专业、年级、班级是怎么被拆开的

概念结构设计部分列出了七个实体：学院、专业、年级、班级、学生、课程、教师。这七个实体不是拍脑袋来的，而是从"学生属于哪个班、班属于哪个专业、专业属于哪个学院"这条现实链路一层层剥出来的。剥到年级这一层时出了个岔子，值得单独说。

原文对关系的描述里有一句是这么写的："一个专业有多个年级，一个年级有多个专业，因此学院与专业之间具有多对多关系。"这句话的主语写错了，前半句说的是专业与年级，结论却拐到了学院与专业上。实际想表达的是专业和年级之间是多对多：计算机专业有 2022、2023、2024 三个年级，而 2023 级又同时存在于计算机、英语、会计多个专业里。学院与专业仍然是一对多，一个学院下有多个专业，一个专业只归属一个学院。

这个多对多一旦落到表上，麻烦就来了。原文把年级单独做成一张 grades 表，主键是 grade 这个 int 字段：

-- 年级表的原始定义 CREATE TABLE grades( grade int not null primary key, collegename varchar(20) not null, majorname varchar(20) not null, FOREIGN KEY (collegename) REFERENCES college(collegename), FOREIGN KEY (majorname) REFERENCES major(majorname) )

问题出在主键上。grade 是主键，意味着全库只能存在一个"2023"——2023 级计算机专业插进去之后，2023 级英语专业再插就会主键冲突。而按多对多的语义，这两条记录本该同时存在。合格的做法是把主键改成(grade, majorname)的联合主键，或者干脆不要 grades 这张表，把 grade 内联到 classes 里做联合主键的一部分。我一般倾向后者，因为年级本身没有独立的业务属性，它只是班级的一个维度标签，单独成表除了多一次 join 没有任何收益。

2.3 多对多关系里，成绩为什么必须挂在选课表上

七个实体里真正需要中间表的只有两处：学生和课程、教师和课程。学生选课是多对多，一个学生选多门课，一门课被多个学生选；教师任课也是多对多，一个老师教多门课，一门课可能有多个老师。这两组关系各自生成一张关联表，selectcourse 和 teachercourse。

关键在于成绩这个属性放在哪。成绩描述的不是学生，也不是课程，而是"某个学生选了某门课"这一件具体的事，所以它只能挂在 selectcourse 上：

create table selectcourse( sno char(10) not null, -- 学号，外键指向 student Cno char(10) not null, -- 课程号，外键指向 course teacherID varchar(10), -- 任课教师，外键指向 teachers score int, -- 成绩，联系属性 primary key(sno, cno), -- 联合主键，一个学生一门课只能有一条记录 foreign key(sno) references student(sno), foreign key(cno) references course(cno), foreign key(teacherID) references teachers(teacherID) )

联合主键(sno, cno)这一行是整个设计里最不能省的一笔。它同时承担两个职责：一是保证同一个学生不能对同一门课重复选课，二是给"按学生查成绩""按课程查平均分"这两类高频查询提供天然的复合索引。如果没有这个主键，重复录入的成绩会直接把后面 avg_s 视图算出的平均分拉偏，而且查起来毫无知觉。teacherID 放在这张表里而不是只放 teachercourse 里，是为了让成绩能直接对应到具体哪位老师给的，省一次三表 join。

E-R 图那部分原文用的是纯文字描述加一堆箭头，读起来比较费劲。真正落到设计上只要盯住三点：所有一对多关系都靠外键实现，所有多对多关系都必须有中间表，所有联系属性（成绩）必须挂在中间表上。把这三条记住，七个实体怎么变成九张表就一目了然了。

3. 物理结构落地：九张表的建表顺序、外键和索引怎么定

3.1 建库语句里的 filegrowth 和文件路径，别照抄

实施阶段的第一条脚本是建库，原文写得挺完整：

create database studentmanagesystem on primary( name = 'studentmanagement', filename = 'D:\DATA\studentmanagesystem.mdf', size = 3, -- 初始大小 3MB maxsize = unlimited, -- 不限制增长上限 filegrowth = 1 -- 每次增长 1MB ) log on( name = 'studentmanagesystem_log', filename = 'D:\DATA\studentmanagesystem_log.ldf', size = 1, -- 日志初始 1MB maxsize = 2, -- 日志上限 2MB filegrowth = 10% -- 每次增长 10% )

参数说明上，size 和 maxsize 不写单位时默认是 MB，filegrowth 写数字默认 MB、写百分比才是按比例增长。这段脚本直接抄的最大问题是日志文件的maxsize = 2——日志上限只有 2MB，而 filegrowth 又是按 10% 增长，意味着日志涨到 2MB 就会顶死，任何批量插入或触发器批量回滚都会直接报"日志文件已满"。血泪经验是日志文件不设上限，或者至少给到几百 MB。

另一个问题是文件路径D:\DATA\硬编码。换个机器如果 D 盘没这个目录，建库语句会直接失败，报错信息还比较隐晦，提示的是操作系统错误而非 SQL 错误。我一般会先单独跑一句EXEC xp_create_subdir 'D:\DATA'，或者在脚本开头加个判断文件夹是否存在的说明，让后续接手的人知道要先建目录。

3.2 九张表的建表顺序：外键决定了谁先出生

九张表之间有密集的外键引用，建表顺序不能随便排。谁被引用，谁就得先建。把依赖关系画出来是这样的：

原文的脚本顺序基本符合这个依赖，但 student 表排在 course 之前、teachers 又排在 depart 之后，中间穿插得比较乱。实际执行时如果顺序错一步，报错是"引用了无效的表 'xxx'"，而且报错只提第一个缺失的外键，改完再跑又冒出下一个，来回好几轮。建议按上表的顺序一次性排好，别边跑边调。

核心几张表的建表语句值得逐字看一遍。college 和 major 是所有业务的根：

-- 学院表：学院名称做主键 CREATE TABLE college( collegename varchar(20) primary key not null, collegeID int not null ) -- 专业表：专业名称做主键，学院名称做外键 CREATE TABLE major( majorname varchar(20) primary key not null, majorID int not null, collegename varchar(20) not null, FOREIGN KEY (collegename) REFERENCES college(collegename) )

这里有个值得商榷的选择：两张表都用"名称"而不是"编号"做主键。名称做业务主键的代价是，学院一旦改名，所有引用它的表都要级联更新，而 SQL Server 的外键默认不支持 ON UPDATE CASCADE 跨多层传递，很容易在第三层就卡住。比较稳妥的做法是用 collegeID、majorID 做代理主键，名称做唯一约束，这样改名只动一行。当然课程设计阶段用名称做主键也够用，只要别真的去改学院名就行。

student 表是外键最密集的一张：

create table student( sno char(10) primary key not null, studentname varchar(10) not null, sex 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) )

四个外键把学生的归属关系全锁死了，好处是不会出现"学生挂在一个不存在的班级下"这种脏数据，坏处是插入一个学生之前，学院、专业、年级、班级四条记录必须全部到位。做数据初始化时，必须先灌字典表再灌学生表，顺序反了就会报外键冲突。这段建表还有个隐患：grade引用了 grades(grade)，而 grades.grade 是主键，前面说过一个年级值只能有一行，所以 student 里 grade 这个外键实际上只能取到唯一一个专业下的年级，稍微换专业就插不进去。改法是把 student 里这一列去掉，通过 class 间接确定年级，或者把 grades 的主键改成联合主键后同步修改外键。

3.3 主键用 char(10)、索引建在 age 上，这两个选择要掂量

学号字段sno char(10)用的是定长字符。定长的好处是长度固定、页内偏移可算，索引查找比 varchar 略快；坏处是如果实际学号只有 8 位，每条记录都会补两个空格，占空间且比较时容易踩坑——where sno = '20230001'能匹配，但where sno = '20230001 '和where sno = '20230001'在 char 语义下虽然相等，迁移到其他数据库时行为未必一致。现在新建库我基本都用 varchar(20)，除非有明确的历史数据格式约束。

索引部分原文建了三个：

-- 在成绩上建非聚集索引 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)

成绩索引是合理的，按分数段查学生、算排名都用得上。但年龄上建索引意义不大——年龄字段本身区分度低（一个班的学生年龄可能只有三四种取值），选择率极差，优化器大概率不会走这个索引，反而每次 insert 都要多维护一个索引页。属于典型的"为了凑索引数量而建的索引"。

真正该建索引但原文没建的，是 selectcourse 表上的cno和teacherID。现在这张表的联合主键是(sno, cno)，按学号查很快，但按课程号查（比如算某门课的平均分）就要全表扫。补一个create index idx_cno on selectcourse(cno)和create index idx_teacher on selectcourse(teacherID)，效果比那两个 age 索引实在得多。

4. 视图与存储过程：把散落的查询封成能直接 exec 的接口

4.1 视图不是装饰：把 group by 写对的几个细节

原文建了十个视图，覆盖学生、班级、学院、课程、成绩、教师、教研室等各个角度。这些视图大部分是"带 where 的查询"或者"多表 join"，思路没问题，但有几处写法会直接报错或者结果不对。

最典型的是跨学院专业视图：

create view c_major_view(collegename,collegeID,majorname,majorID) as select collegeID, college.collegename, majorID, majorname from college, major where major.collegename = college.collegename

视图头部的列名列表顺序是(collegename, collegeID, majorname, majorID)，而 select 出来的字段顺序是(collegeID, collegename, majorID, majorname)。SQL Server 会按位置一一对应，结果就是 collegename 列里装的是 collegeID 的 int 值，反过来 collegeID 列里装的是学院名字符串，类型不匹配时直接报转换错误。这类错误跑一遍就能发现，但如果只做静态检查，肉眼很容易滑过去。修正很简单，把列名列表和 select 的字段顺序对齐：

-- 修正版：列名列表与 select 字段一一对应 create view c_major_view(collegename, collegeID, majorname, majorID) as select college.collegename, college.collegeID, major.majorname, major.majorID from college, major where major.collegename = college.collegename

另一类是 group by 的滥用。比如 class_s 视图：

create view class_s as select sno, studentname, grade, class, tel from student group by collegename, majorname, grade, class, sno, studentname, tel

这段能执行，但 group by 里塞了 select 中没出现的 collegename 和 majorname，效果等同于按全部字段去重，和直接写 select distinct 没区别。这类"为了显得严谨"而写的 group by，在数据量小的时候看不出问题，一旦 student 表上了几万行，排序去重的开销就白花了。

真正有价值的视图是跟成绩相关的两个。avg_s 算每个学生的平均分：

create view avg_s(sno, grade, class, gavg) as select selectcourse.sno, grade, class, avg(score) from selectcourse, class_s where selectcourse.sno = class_s.sno group by grade, class, selectcourse.sno

这个视图的意义在于，把"按班级按学生算平均分"这个每次都要写 group by 的动作固化下来，后面做班级排名、做成绩单导出，直接select * from avg_s where grade = 2023 and class = 'CS2301'就行。注意它的 grade 和 class 来自 class_s 而不是 selectcourse，因为 selectcourse 里没有这两个字段，join 之后才能取到。这一点在改视图时需要留心，删掉 class_s 这个依赖会让 avg_s 直接失效。

4.2 五个存储过程，output 参数怎么接

存储过程是这份文档里最像"工程代码"的部分。原文设计了五个，覆盖学生成绩查询、课程平均分统计、学院专业列表、班级学生名单、教师任课情况。这里拿两个有代表性的说说 output 参数怎么用。

第一个是纯查询型的，输入学号返回各科成绩：

create proc scoreproc @sno char(10) -- 入参：学号 as begin select student.sno, studentname, coursename, score, credit from student, course, selectcourse where student.sno = selectcourse.sno and course.cno = selectcourse.cno and student.sno = @sno end go

这个很简单，三表 join 加一个 where 过滤，调用时exec scoreproc '2023000101'就能出结果。参数类型用 char(10) 和 student.sno 保持一致，避免隐式转换导致索引用不上。

第二个带 output 参数，输入课程名返回平均分和选课人次：

create proc avgscoreproc @cname char(20), @avg int output, -- 出参：平均分 @count smallint output -- 出参：选课人次 as begin select @avg = avg(grade), @count = count(*) from course, selectcourse where course.cno = selectcourse.cno and coursename = @cname end go -- 调用方式：先声明变量接出参 declare @a int, @b smallint exec avgscoreproc '数据库原理', @a output, @b output select @a as 平均成绩, @b as 选课人次

这段有个必须改的 bug：selectcourse 表里根本没有 grade 这个列，成绩字段叫 score。avg(grade)在执行时会报"列名 'grade' 无效"。改成avg(score)就对了。另外@avg int把平均分截成整数了，如果课程成绩本身是整数，平均下来会出现 .5 之类的值，用 int 接会丢精度，建议改成 decimal(5,2)。

output 参数的调用规矩要记住两条：声明时必须带 output 关键字，exec 传参时也必须再带一次 output。少任何一个，变量拿到的都是 null，而且不会报错，属于典型的黑匣子式沉默失败。

第三个 majorproc 展示的是"查询结果集 + 出参统计"的混合模式：

create proc majorproc @collegename char(20), @countmajor int output as begin -- 第一个结果集：该学院下所有专业 select college.collegeID, collegename, majorID, majorname from college, major where college.collegename = major.collegename and college.collegename = @collegename -- 出参：专业总数 select @countmajor = count(*) from major where collegename = @collegename end go

一个存储过程里同时返回结果集和出参，调用方既要遍历结果集又要读出参，在 ADO.NET 或 JDBC 里要多写几行。这种混合模式在课程设计里很常见，实际项目里我一般拆成两个过程，一个只返回列表，一个只返回计数，调用方按需取，代码更清晰。

4.3 调用与验证：从 exec 到结果集

五个过程写完之后，必须逐个跑一遍验证。原文给的调用示例里有几处拼写问题，直接抄会报错：exec classprco应该是exec classproc；teacherproc 的参数定义@college char(10) outchar里 outchar 是笔误，应该写 output。

验证顺序建议按依赖从少到多来：先跑 scoreproc，它只依赖 student、course、selectcourse 三张表，需要先灌入至少一个学生、一门课、一条选课记录；再跑 avgscoreproc，同样依赖这三张表；然后跑 majorproc 和 classproc，依赖学院、专业、班级；最后跑 teacherproc，它要等 teachers、teachercourse、depart 全都有数据。每跑一个，先看有没有报错，再看结果集列名对不对，最后看出参的值是不是 0——出参是 0 要么是真的没数据，要么是 output 忘了写，两种情况要分清。

5. 触发器排查实录：递归插入、列名错位和五条翻车记录

5.1 五条翻车记录：现象、原因、解决

原文一共设计了十几个触发器，分三类：级联删除和级联更新、插入时的合法性校验、插入后的数据同步。数量不少，但能直接跑通的不到一半。下面五条是照着脚本实际执行时最容易撞上的，每条按现象、原因、解决来记。

第一条：建表建到一半报"引用了无效的表"。现象：按文档顺序从 college 一路往下建，到 classes 时报错，提示外键引用的 grades 表不存在。 原因：文档里的建表语句是分块展示的，实际执行时 grades 那段可能被跳过，或者执行顺序被打乱。外键是强依赖，被引用的表必须先存在。 解决：按 3.2 节的顺序表重排，或在脚本前面加SET NOEXEC OFF之外的手动检查，最简单的是把所有建表语句按依赖顺序排成一个文件一次跑完。

第二条：触发器 insert_student 一插就死循环。现象：往 student 表插一条记录，语句一直不返回，CPU 拉满，最后报"递归触发器超出最大嵌套层数"。 原因：

-- 原始触发器：在 student 的 after insert 里又向 student 插数据 create trigger insert_student on student after insert as begin insert into student values('sno','studentname','sex','sage','collegename','majorname','grade','class','tel') end

after insert 触发后执行 insert into student，又会触发这个触发器，无限套娃。而且 values 里写的是字段名字符串，不是实际变量。 解决：这个触发器本身没有存在的意义——往 student 插数据不需要再往 student 插一遍。直接删掉。同类问题还出现在 insert_classes、insert_college、insert_course 等六个触发器上，全都是自我插入，全部删掉。

第三条：更新学号时外键冲突。现象：执行update student set sno = '新学号' where sno = '旧学号'，报"UPDATE 语句与 REFERENCE 约束冲突"。 原因：student.sno 被 selectcourse.sno 引用，而外键定义时没写 ON UPDATE CASCADE。SQL Server 默认阻止更新被引用的主键。 解决：要么在 selectcourse 的外键上补ON UPDATE CASCADE，要么先禁用外键再更新再启用。原文想用触发器 strigger 解决，但那个触发器本身语法就有问题：

-- 原始写法：set 子句用 in，SQL Server 不支持 update selectcourse set sno in (select sno from inserted) where sno in (select sno from deleted)

正确写法是基于 inserted 和 deleted 做 join：

create trigger trg_student_sno_update on student after update as begin if update(sno) begin update sc set sc.sno = i.sno from selectcourse sc inner join deleted d on sc.sno = d.sno inner join inserted i on i.sno <> d.sno end end

第四条：校验触发器用 rollback 把整笔业务都回滚了。现象：插入一条选课记录，因为学号不存在被拦截，但之前同一批次里插进去的另外几条合法记录也消失了。 原因：after 触发器里的 rollback 回滚的是整个事务，不是单条语句。原文的 check_trig 就是这种写法，而且里面引用的s表根本不存在，应该是 student。 解决：课程设计里可以用 instead of insert 做前置校验，或者在应用层先查后插。生产环境更常见的是用 check 约束加应用层校验，而不是靠触发器 rollback。

第五条：视图依赖链断了，改表之后视图全红。现象：把 grades 表删掉重建，之后查询 avg_s、class_s 全部报"对象无效"。 原因：视图是强依赖的，底层表结构一变，引用它的视图不会自动修，要手动 sp_refreshview。 解决：改完表结构后统一跑一遍exec sp_refreshview '视图名'，或者exec sp_refreshsqlmodule刷存储过程。

5.2 触发器里 inserted 和 deleted 的正确用法

触发器最容易写错的地方是对 inserted 和 deleted 的理解。这两个是逻辑表，after insert 时 deleted 为空、inserted 有新行；after delete 时 inserted 为空、deleted 有旧行；after update 时两张表都有值，分别对应更新前和更新后。它们可能包含多行，所有操作都必须按集合处理，不能假设只有一行。

原文的级联删除触发器方向是对的，但表名写错了：

-- 原始：SC 表不存在，实际表名是 selectcourse create trigger ctrig on course after delete as begin delete SC where cno in (select cno from deleted) end

改成 selectcourse 就能用。不过要注意，如果 selectcourse 的 cno 外键已经定义了 ON DELETE CASCADE，这个触发器就是多余且冲突的，两者同时存在会报错。二选一，要么用外键级联，要么用触发器，别都写。

插入校验的正确写法是 instead of，拦截在写入之前：

-- 校验学号和课程号是否存在，不存在就不插 create trigger trg_check_selectcourse on selectcourse instead of insert as begin 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 的好处是非法数据压根不会进表，不需要 rollback 整个事务，也不会误伤同批次的其他记录。

5.3 改完之后怎么验证

触发器改完必须做三组验证：正常插入一条合法数据，看是否成功且相关表同步；插入一条非法数据，看是否被拦截且其他数据不受影响；批量插入十条混合数据，看是否只拦非法的、合法的全进。第三组最关键，因为单条测试永远发现不了"触发器只处理了 inserted 第一行"这类问题。验证完记得select * from sys.triggers看一眼有没有遗留的旧触发器还在生效，改名字不改逻辑的情况在课设脚本里太常见了。

6. 二次开发：把触发器逻辑搬到应用层，顺便把 SQL Server 2005 挪到新版

这个库拿来当课设交作业是够的，但要真做成一个能用的系统，第一件该做的事是把触发器砍掉一半。级联删除、级联更新、插入同步这三类逻辑，在现代后端里都有更可控的实现方式——级联用外键的 ON DELETE CASCADE，更新用应用层事务包起来，同步用服务层统一写入。触发器的问题在于它藏得太深，一个 insert 语句背后可能牵动五张表，出问题时排查链路极长。我现在的习惯是：能在应用层写清楚的业务规则，一律不放进数据库。

第二件是版本迁移。SQL Server 2005 的语法在新版本上大部分兼容，但有几处要改：varchar不带长度在旧版默认 1 或 30，新版行为不同，所有 varchar 都要补长度；group by里出现 select 没有的列在严格模式下会报错；sp_refreshview在新版建议换成sp_refreshsqlmodule。如果打算换成 MySQL，还要额外处理char(10)尾部空格比较、instead of触发器不支持、output参数改成OUT这几处。迁移前先把所有脚本在一个空库里跑一遍，报错列表就是改造清单。

第三件是把账号体系补上。原来那张 system 表只有账号和操作两个字段，改造后至少要有角色、密码哈希、关联 ID：

登录时先按 account_id 查角色，admin 走全表查询接口，student 强制在 SQL 里拼上where sno = ref_id，这样即使前端传了别人的学号也查不出来。这一步做完，原文里"系统能自动识别用户类型并分配不同权限"这句需求才算真正落地。

最后提一个改造时容易忽略的点：所有涉及多表写入的操作，比如"新增学生同时建选课记录"，必须包在事务里。原文的存储过程和触发器各自为战，没有任何事务边界，中途失败会留下半条数据。我的习惯是每个写操作入口都套一层begin tran / commit / rollback，哪怕只有两条 insert。之前有一次图省事没加，测试环境跑得好好的，上线后并发一上来就出现学生存在但选课记录丢失的情况，查了两天才定位到。从那以后我每次动数据库脚本，都强制先把事务边界画出来再写 SQL。希望这些能帮到你少走点弯路。

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