数据库课程设计避坑：从E-R图到SQL Server建表与触发器

简介《数据库系统概论》课程设计报告——学生选课管理信息系统面向高校数据库课程设计、期末大作业与答辩准备场景适合需要参考完整设计流程与文档写法的本科生及任课教师。压缩包内仅含1个docx文档大小约3.96MB按需求分析、概念结构设计、逻辑结构设计、物理实现、功能调试与应用程序设计组织目录层级清晰。内容覆盖可行性分析与功能需求、组织结构与业务流/数据流分析、数据字典、CDM与PDM建模以及SQL Server表结构、完整性约束、视图、索引、存储过程和触发器的创建代码后段还给出学生信息、课程信息、登录与成绩管理模块的调试与设计示例。已有852人学习可作为课程设计范文、模板与素材帮助读者快速搭建报告框架、对照SQL实现并梳理答辩要点。1. 答辩前一周被退回的数据库课程设计问题往往不在功能每年这个节点都有人拿着一份《学生选课管理信息系统》的数据库课程设计报告来找我封面、目录、页码全齐E-R 图也画了翻到第四部分却发现建表脚本里SC表的外键指向一张还没建的course表脚本一执行就报引用了无效的对象名。这类报告翻车的地方从来不是功能没写完而是需求分析、概念模型、物理实现三段各写各的接不上。手上这份课程设计报告模板把需求分析、数据字典、CDM/PDM 图、SQL Server 建表、视图、触发器、存储过程、索引、功能调试和应用程序设计串成了一条线既能直接当数据库课程设计的底稿也能当毕设前期练手用的范文素材——但前提是你知道哪几处必须自己动手改。2. 需求分析写到能验收的颗粒度角色、数据字典与分层数据流图需求分析这一章最容易被写成流水账方便了教师也方便了学生这类句子写十行也不产生一行 DDL。合格的标准很朴素这一章写完之后后面建表时不用再回头补字段、加实体。所以本章按角色定权限、字典定字段、数据流定边界三条线拆。2.1 三类角色与五个功能模块的拆法原报告把系统用户划成教务管理员、开课教师、选课学生三类模块拆成课程管理、学生管理、教师管理、查询管理、数据库管理、选课管理。这个拆法有一处不太顺把查询单独列成一个模块可查询其实是每个模块里的一个动作教师查名单、学生查成绩、管理员查统计都不属于同一个功能边界。我一般会把它拆成业务模块 权限模块两层业务模块管数据怎么变权限模块管谁能变。真正有价值的是把角色和操作落成一张权限矩阵这张表写进需求分析之后后面建视图和数据库角色就有依据了不用临场拍脑袋。功能点教务管理员开课教师选课学生学生/教师信息初始化增、删、改、查只读本人只读本人课程开设申请审批、驳回提交、修改浏览选课时段开关设置、锁定无无选课/退选强制退选查看名单选、退时段内成绩录入归档、锁定录入、修改只读本人数据备份还原执行无无落到 SQL Server 上这三行就是三个数据库角色db_admin、db_teacher、db_student视图和存储过程按角色授权而不是在应用层用 if-else 判断。原报告第六章的登录模块只做了账号密码对不对没做这个账号能看哪些行这在答辩时是会被追问的点——同样是查成绩学生只能看自己的教师只能看自己所教课程的这个过滤条件放在视图里比放在代码里更稳。模块划分还要注意一点功能模块图里的每个叶子节点都要能在后面的数据流图里找到对应的加工找不到就说明这个模块是凭空画出来的。原报告的模块图里有数据库管理这一支如果下面没有备份、还原、日志清理这些具体加工这一支就是虚的答辩时容易被问住。2.2 数据字典的字段类型为什么必须一次定死数据字典是整份报告里最枯燥、也最不能出错的部分。它是后面建表 DDL 的唯一来源改一个字段长度建表语句、视图定义、存储过程参数、前端实体类四处都要跟着改漏一处就是运行时报错。原报告给出的学生、课程、选课、教师四张字典表基本结构是对的字段类型有几处需要动手调数据项含义原报告类型建议类型理由Sno学号Char(10)Char(10)定长、等值查询多定长比较快Spassword密码Char(6)Varchar(64)6 位定长存不下哈希值且定长会补空格Sname姓名Char(10)Nvarchar(20)中文按字符计Char 按字节补位容易截断Sdept系名Char(20)Varchar(30)变长避免大量空格占页Email邮箱Varchar(30)Varchar(60)30 位对部分邮箱不够Grade成绩IntDecimal(5,2)支持 0.5 分制且要配 CHECKCcredit学分Int(3)Decimal(3,1)存在 0.5 学分课程这里有个血泪经验Char(6)存密码这一条几乎每份模板里都有因为它看起来够用。但只要你在报告里写了安全性要求账户密码不可被他人使用字段长度就得给哈希留出空间Varchar(64)是常见做法。同理成绩字段用Int看似省事一旦要做平均分、绩点换算小数部分直接丢失Decimal(5,2)更合适。数据字典还要写清楚谁写入、谁读取。学号是管理员初始化的、学生不能改成绩是教师写入的、学生只读课程学分是教师申请开课时填的、管理员审批后可调。这三句话写进字典备注栏后面设计触发器和权限时能省掉很多争论。2.3 数据流图分层0 层、1 层、2 层各画什么原报告画了 0 层、1 层、2 层三张数据流图方向是对的但很多同学画到 2 层就乱了原因是没搞清楚每层该画多少东西。层次加工编号画什么本系统对应0 层P0整个系统当一个黑匣子只画外部实体与进出数据流学生/教师/管理员 ↔ 选课管理系统1 层P1、P2、P3按角色拆成三个子系统加工学生子系统、教师子系统、管理员子系统2 层P2.1、P2.2…单个子系统内部再拆一般不超过 7 个加工管理员下的用户管理、时段设置、数据备份分层有三条硬规矩。一是父子平衡1 层的输入输出数据流必须和 0 层里对应加工的数据流完全一致不能凭空多出一条。二是数据流闭合任何一个加工都要有输入有输出只进不出比如学生信息录入只画了输入没画写入学生表是最常见的扣分点。三是数据字典里的每个数据项都要在某一层的数据流上出现过否则就是字典里写了、图里没用两边对不上。画 2 层的时候加工编号要带父编号P2.1、P2.2这种写法的好处是评审时一眼能看出它属于哪个父加工。另外数据存储也就是那些双横线在 1 层图上就可以出现不必等到 2 层student、course、sc、teacher四张表在 1 层图上标清楚后面转逻辑模型时几乎可以直接抄。3. 从 E-R 图到建表语句概念模型转逻辑模型的三个判定点概念设计到逻辑设计这一段是整份报告里最能看出功力的地方。E-R 图画得再漂亮转不成带主外键的表结构就是白画。这一段的核心工作量集中在三个判断上哪些东西该独立成表、多对多联系怎么拆、约束写在哪儿。3.1 实体与联系的识别哪些该独立成表原报告识别出学生、课程、教师三个实体加上管理员和选课记录一共五张表。这个划分基本正确但正文里有一处自相矛盾的地方值得拿出来说正文写一名学生可以选择多门课程而一门课程也可以被多名学生选择所以是 n:m 的联系可后面的表格却写成学生 1:N 课程、课程 1:N 教师。这两处必须统一否则逻辑模型没法往下推。判定方法很简单问两个问题一个学生能不能选多门课能。一门课能不能被多个学生选能。两个都能就是 M:N必须拆中间表。教师和课程同理一个教师能教多门课、一门课能有多个教师也是 M:N。而管理员对课程审批一个管理员能审批多门课、一门课只由一个管理员审批这才是 1:N外键放在课程表里就行。还有一个容易漏的点先修课。原报告在选课记录的数据字典里放了Cpno先修课号但这个字段既不属于某学生选了某课这个事实也会导致同一门课有多个先修课时出现重复行。先修课本质上是课程对课程的自反 M:N 联系正确做法是独立建一张表。-- 课程先修关系课程对课程的自反多对多必须独立成表 CREATE TABLE course_prev ( cno CHAR(7) NOT NULL, -- 本课程号 pcno CHAR(7) NOT NULL, -- 先修课程号 CONSTRAINT pk_course_prev PRIMARY KEY (cno, pcno), CONSTRAINT fk_cp_cno FOREIGN KEY (cno) REFERENCES course(cno), CONSTRAINT fk_cp_pcno FOREIGN KEY (pcno) REFERENCES course(cno), CONSTRAINT ck_cp_self CHECK (cno pcno) -- 不允许自己成为自己的先修课 );这段 DDL 的关键在最后两行。复合主键(cno, pcno)保证同一对先修关系不会重复插入两个外键都指向course(cno)这是自反联系的标志CHECK (cno pcno)把课程不能是自己的先修课这条业务规则下沉到数据库应用层忘了校验也不会写进脏数据。3.2 多对多联系拆中间表与外键方向选课关系的中间表SC字段是学号、课程号、成绩主键是(sno, cno)两个外键分别指向学生表和课程表。这里有个细节主键的顺序会直接影响索引的可用性。(sno, cno)这个顺序天然支持按学号查这个学生选了哪些课但按课程号查这门课有哪些学生就得全表扫。教师看名单、统计选课人数走的都是后一条路所以后面必须给cno单独补一个非聚集索引。授课关系同理teachingplan(cno, tno)是复合主键两个外键分别指向课程和教师。如果一门课只允许一个教师主讲那就不该用 M:N直接在course表里放tno外键更省事。原报告在这里是两头都想兼顾既写了一门课程可以由多名老师授课又在课程表里放了Tno两套并存会导致同一事实存两遍改一处另一处不同步。选一种别都留。中间表还要想清楚成绩为空的含义。grade允许 NULL表示已选课但未出分这和没选这门课是两回事。如果grade设成NOT NULL DEFAULT 0统计平均分时就会把没出分的记录算成 0 分数据直接失真。3.3 主键、外键与完整性约束的落法建表阶段真正要决策的是约束放在数据库还是放在代码。我的习惯是能在数据库层表达的业务规则一律下沉到数据库应用层只做友好提示。原因是课程设计这类系统通常只有一个应用入口但答辩演示时经常直接用 Management Studio 改数据代码层的校验根本拦不住。约束类型本系统落点说明主键student(sno)、course(cno)、teacher(tno)、sc(sno,cno)中间表用复合主键不另设自增 ID外键sc.sno→student、sc.cno→course默认 NO ACTION禁止级联删除唯一course(cname, term)同一学期不允许同名课程检查grade BETWEEN 0 AND 100、ssex IN (男,女)业务规则下沉默认sc.grade 默认 NULL区分未出分与0 分外键的删除策略要特别说明。学生退学、课程下架都不应该级联删掉选课记录历史数据要留着做统计和审计。所以外键一律用默认的NO ACTION真要删就先删子表再删父表或者在应用层做逻辑删除加一个status字段。这一点写进报告的设计说明里比只贴一段建表代码有说服力得多。4. SQL Server 物化建表顺序、视图、触发器、存储过程与索引物理设计这一段是整份报告里唯一跑起来就能验证对错的部分。顺序错了脚本报错触发器写错了数据不对索引建错了查询慢——每一条都能在功能调试章节里找到对应的测试记录。4.1 建表顺序与外键依赖外键要求被引用的表先存在所以建表顺序不是随便排的student、teacher无外键依赖course依赖teacher.tnosc依赖student、courseteachingplan依赖course、teachercourse_prev两次依赖coursemanage独立原报告的建表脚本是按报告目录顺序贴的课程表在前、学生表在后SC表的外键指向还没建的student直接执行必然失败。规范的写法是脚本开头先按依赖反序删除再按依赖正序创建这样脚本可以反复执行不报错。-- 重建脚本先按依赖反序删除再按依赖正序创建 IF OBJECT_ID(dbo.sc, U) IS NOT NULL DROP TABLE dbo.sc; IF OBJECT_ID(dbo.course_prev, U) IS NOT NULL DROP TABLE dbo.course_prev; IF OBJECT_ID(dbo.teachingplan, U) IS NOT NULL DROP TABLE dbo.teachingplan; IF OBJECT_ID(dbo.course, U) IS NOT NULL DROP TABLE dbo.course; IF OBJECT_ID(dbo.student, U) IS NOT NULL DROP TABLE dbo.student; IF OBJECT_ID(dbo.teacher, U) IS NOT NULL DROP TABLE dbo.teacher; GO CREATE TABLE teacher ( tno CHAR(5) NOT NULL, tname NVARCHAR(20) NOT NULL, tdept VARCHAR(30) NOT NULL, duty NVARCHAR(10) NULL, -- 职称 telephone VARCHAR(12) NULL, CONSTRAINT pk_teacher PRIMARY KEY (tno) ); CREATE TABLE course ( cno CHAR(7) NOT NULL, cname NVARCHAR(40) NOT NULL, term INT NOT NULL, -- 开课学期如 202401 tno CHAR(5) NULL, -- 主讲教师允许暂缺 ccredit DECIMAL(3,1) NOT NULL, capacity INT NOT NULL DEFAULT 60, -- 选课容量模板里常缺这个字段 CONSTRAINT pk_course PRIMARY KEY (cno), CONSTRAINT fk_course_teacher FOREIGN KEY (tno) REFERENCES teacher(tno), CONSTRAINT ck_course_credit CHECK (ccredit 0 AND ccredit 10), CONSTRAINT ck_course_capacity CHECK (capacity 0) ); CREATE TABLE sc ( sno CHAR(10) NOT NULL, cno CHAR(7) NOT NULL, grade DECIMAL(5,2) NULL, -- NULL 表示已选未出分 CONSTRAINT pk_sc PRIMARY KEY (sno, cno), CONSTRAINT fk_sc_student FOREIGN KEY (sno) REFERENCES student(sno), CONSTRAINT fk_sc_course FOREIGN KEY (cno) REFERENCES course(cno), CONSTRAINT ck_sc_grade CHECK (grade IS NULL OR (grade 0 AND grade 100)) );course.capacity这个字段原报告没有但选课系统不给容量上限触发器里就没有东西可校验答辩时选课人数超了怎么办这个问题没法回答。加字段属于合理补全报告里加一句设计说明即可。ck_sc_grade这一条写成grade IS NULL OR (...)而不是直接grade BETWEEN 0 AND 100是因为NULL BETWEEN 0 AND 100结果是 UNKNOWN约束会放行这正好符合预期但写清楚意图能避免别人误读。4.2 视图设计三类用户各看什么视图在这个系统里承担两件事一是按角色裁剪列学生不该看到密码字段二是按角色裁剪行学生只能看自己的成绩。这两件事用视图做比用应用代码做更可靠因为直接连数据库也绕不过去。-- 学生成绩视图只暴露学号、姓名、课程名、学分、成绩不出现任何密码字段 CREATE VIEW vs_student_score WITH SCHEMABINDING AS SELECT s.sno, s.sname, c.cno, c.cname, c.ccredit, sc.grade FROM dbo.student AS s JOIN dbo.sc AS sc ON sc.sno s.sno JOIN dbo.course AS c ON c.cno sc.cno; GO -- 教师名单视图只给教师看自己所教课程的选课名单 CREATE VIEW vs_teacher_roster AS SELECT c.tno, c.cno, c.cname, s.sno, s.sname, s.sdept, sc.grade FROM course c JOIN sc sc ON sc.cno c.cno JOIN student s ON s.sno sc.sno; GOWITH SCHEMABINDING的作用是把视图和基表的列绑定起来基表想改列类型或删列必须先删视图避免视图建好了、基表一改就报错这种隐蔽故障。代价有两条查询里必须写两段式名称dbo.xxx且不能用SELECT *。这两条看着麻烦其实是好事逼着你把列清单写死。vs_teacher_roster里没有加WHERE tno ...过滤是因为视图没法知道当前登录的是谁。常见做法是在应用层传参查这个视图或者给每个教师建一个带CURRENT_USER判断的视图不推荐用户一多就是灾难。报告里写清楚行级过滤在应用层拼参数完成比含糊带过要专业。WITH CHECK OPTION这个选项要慎用。它只对可更新的简单视图有效一旦视图里带 JOIN 或聚合更新本来就不允许加了也是摆设。原报告里给学生基本信息建的视图是单表查询那种场景才适合加。4.3 触发器选课容量与成绩录入边界触发器要解决的是跨表的业务规则。选课这个动作既要往sc插一行又要确认这门课没满、这个学生没重复选、先修课已修完——三件事必须原子完成。用触发器做前置校验比在应用层写三个 if 更稳因为它对所有写入路径都生效。CREATE TRIGGER trg_sc_insert_check ON sc AFTER INSERT AS BEGIN SET NOCOUNT ON; -- 1) 重复选课按 inserted 集合判断不要用变量接单行 IF EXISTS ( SELECT 1 FROM inserted i JOIN sc ON sc.sno i.sno AND sc.cno i.cno GROUP BY i.sno, i.cno HAVING COUNT(*) 1 ) BEGIN RAISERROR(该学生已选过此课程, 16, 1); ROLLBACK TRANSACTION; RETURN; END -- 2) 容量校验统计已选人数是否超过课程容量 IF EXISTS ( SELECT 1 FROM inserted i JOIN course c ON c.cno i.cno WHERE (SELECT COUNT(*) FROM sc WHERE sc.cno i.cno) c.capacity ) BEGIN RAISERROR(该课程选课人数已满, 16, 1); ROLLBACK TRANSACTION; RETURN; END -- 3) 先修课校验存在未通过的先修课则拒绝 IF EXISTS ( SELECT 1 FROM inserted i JOIN course_prev cp ON cp.cno i.cno WHERE NOT EXISTS ( SELECT 1 FROM sc WHERE sc.sno i.sno AND sc.cno cp.pcno AND sc.grade 60 ) ) BEGIN RAISERROR(先修课程未通过不能选修本课程, 16, 1); ROLLBACK TRANSACTION; RETURN; END END;逻辑说明三个校验全部基于inserted这张逻辑表做集合判断没有一处写SELECT sno sno FROM inserted。后者是触发器里最常见的翻车写法——一次插入多行时变量只会拿到其中一行其余行静默通过校验。参数说明RAISERROR的第二个参数16表示一般性用户错误能被应用层捕获ROLLBACK TRANSACTION放在RETURN之前确保校验失败时整个语句回滚。成绩触发器只做一件事成绩一旦录入并被管理员归档就不允许再改。CREATE TRIGGER trg_sc_grade_lock ON sc AFTER UPDATE AS BEGIN SET NOCOUNT ON; IF EXISTS ( SELECT 1 FROM inserted i JOIN deleted d ON d.sno i.sno AND d.cno i.cno WHERE d.grade IS NOT NULL AND i.grade d.grade AND EXISTS (SELECT 1 FROM course WHERE cno i.cno AND term 202401) ) BEGIN RAISERROR(往期课程成绩已归档不允许修改, 16, 1); ROLLBACK TRANSACTION; END END;这里用inserted和deleted对比才能判断出成绩被改过而不是成绩被写入。AFTER UPDATE触发器里两个逻辑表同时存在这是它和 INSERT 触发器的关键差别。4.4 存储过程与索引把查询压到索引上选课这个动作如果只靠触发器有个绕不开的问题并发。两个学生同时抢最后一个名额两边都查到当前 59 人都判断没满最后插进去 61 人。触发器里的COUNT(*)在默认隔离级别下读不到对方未提交的插入拦不住这种情况。CREATE PROCEDURE usp_enroll sno CHAR(10), cno CHAR(7) AS BEGIN SET NOCOUNT ON; SET XACT_ABORT ON; -- 出错自动回滚不用手写一堆 IF ERROR BEGIN TRY BEGIN TRANSACTION; -- 对课程行加更新锁把并发选课串行化到同一门课上 IF NOT EXISTS ( SELECT 1 FROM course WITH (UPDLOCK, HOLDLOCK) WHERE cno cno ) THROW 50001, 课程不存在, 1; IF EXISTS (SELECT 1 FROM sc WHERE sno sno AND cno cno) THROW 50002, 已选过该课程, 1; INSERT INTO sc (sno, cno, grade) VALUES (sno, cno, NULL); COMMIT TRANSACTION; END TRY BEGIN CATCH IF TRANCOUNT 0 ROLLBACK TRANSACTION; THROW; -- 把原始错误抛给调用方不吞异常 END CATCH END;逻辑说明WITH (UPDLOCK, HOLDLOCK)是这段代码的核心它在course表的目标行上加更新锁并持有到事务结束后来者必须等前一个事务提交才能继续容量判断因此变得可信。SET XACT_ABORT ON让运行时错误自动回滚整个事务省掉逐句判断ERROR的样板代码。THROW不带参数重新抛出当前错误保留了原始错误号和消息排查时能看到是哪一条校验拦下来的。索引要跟着查询走不是越多越好-- 按课程查名单、统计选课人数SC 的主键是 (sno, cno)按 cno 查用不上 CREATE NONCLUSTERED INDEX ix_sc_cno ON sc(cno) INCLUDE (sno, grade); -- 按教师查所教课程 CREATE NONCLUSTERED INDEX ix_course_tno ON course(tno) INCLUDE (cname, term); -- 按学期筛课程 CREATE NONCLUSTERED INDEX ix_course_term ON course(term) INCLUDE (cname, ccredit);INCLUDE的作用是把查询要用到但不需要排序的列放到索引叶子页查询时只读索引不回表。ix_sc_cno把sno和grade带进去之后查某门课的学生名单和成绩这条最热的 SQL 可以完全走索引。反过来如果给sc.grade单独建索引选择性太低成绩就那么几十个取值优化器根本不会用白白拖慢插入。5. 避坑与排查五个让报告被打回的具体问题以下五条都是我在帮人看报告时反复见到的每条按现象—原因—解决写能对上号的直接改。5.1 建模与约束阶段的三个坑坑一先修课字段放错表。现象把Cpno放进SC表的数据字典后一门课有两个先修课时同一学生的选课记录出现两行主键冲突。 原因先修课是课程自身的属性跟谁选了这门课无关放在选课表里就变成每选一次课重复存一遍。 解决独立建course_prev(cno, pcno)表SC表只保留sno、cno、grade三个字段。坑二建表脚本顺序错一执行就报错。现象脚本跑到SC表时报引用了无效的对象名 student或者重复执行时报数据库中已存在名为 sc 的对象。 原因外键要求父表先存在而脚本按报告章节顺序贴没有考虑依赖同时缺少删除语句脚本不可重复执行。 解决脚本开头按依赖反序加IF OBJECT_ID(...) IS NOT NULL DROP TABLE ...创建时按父表到子表排序中间用GO分批。坑三密码字段定长且明文。现象Spassword CHAR(6)在演示时看着没问题一旦要求密码不可被他人使用长度放不下哈希值改成明文存储又和安全性要求自相矛盾。 原因模板沿用了早期教学案例的字段定义没有考虑存储形态。 解决改成VARCHAR(64)存哈希报告里在数据字典备注栏写明存储密码摘要不存明文安全性要求那一段才站得住。5.2 调试与演示阶段的另外两个坑坑四触发器一次插入多行只校验了一行。现象单条INSERT选课一切正常用INSERT ... SELECT批量导入历史选课数据时容量已满的课程照样插进去了。 原因触发器里写了SELECT cno cno FROM inserted多行插入时变量只保留最后一行其余行没进校验逻辑。 解决所有判断改成基于inserted的EXISTS集合判断禁止用变量从inserted取值。压测时用一条批量插入语句验证不要只测单行。坑五视图用SELECT *基表加列后报错。现象给student表加了一个status字段后原来的学生视图查不出数据或者报列名或所提供值的数目与表定义不匹配。 原因视图创建时把*展开成了当时的列清单基表结构一变就对不上如果视图还带了SCHEMABINDING改列会直接失败。 解决视图一律写显式列清单加SCHEMABINDING时用两段式表名。改基表结构前先DROP VIEW改完重建。6. 让报告能跑起来测试用例表与答辩前的自检清单报告写得再厚答辩现场也是让你打开 Management Studio 当场跑。我一般会让学生准备一张测试用例表每条用例对应一个约束或触发器跑一条勾一条被问到你怎么证明这个约束生效了时直接翻表。编号测试场景输入预期结果T01正常选课学生 S1 选课程 C1插入成功sc多一行T02重复选课同一学生再选 C1报已选过该课程行数不变T03容量已满第 61 人选容量 60 的课报选课人数已满事务回滚T04先修课未过先修课成绩 55 分再选后续课报先修课程未通过T05成绩越界录入 150 分CHECK约束拒绝T06归档后改分修改往期课程成绩报已归档不允许修改T07并发抢课两个会话同时执行usp_enroll一个成功一个失败总人数不超容量T07 这条最容易被跳过但它恰恰是答辩时最有说服力的演示开两个查询窗口都先BEGIN TRAN不提交你会看到第二个窗口卡住等锁提交第一个之后第二个才继续判断容量。这个卡住的现象本身就是加锁生效的证据。答辩前的自检清单我一般就照这几条走一遍建表脚本能不能从空库一次跑通、跑第二遍会不会报错所有视图是不是都写了显式列清单、SCHEMABINDING的视图是不是都用了dbo.前缀触发器里有没有出现SELECT 变量 列 FROM insertedsc表上按cno查的执行计划是不是走了ix_sc_cnograde字段里有没有 150 分、-1 分这种脏数据三个数据库角色的权限是不是真的只到视图和存储过程没有直接给表权限。那次一个同学的报告被打回就是因为自检清单里脚本跑第二遍这一条没做——他演示到一半手滑重跑了一次建表脚本sc表已存在直接报错后面十分钟全在解释。从那以后我每次交任何带 DDL 的东西都强制先把删了重建、建完再删走一遍确认脚本真能反复跑才敢按下提交。希望帮到你。本文还有配套的精品资源点击获取