简介：《Oracle数据库课程设计》是一份面向高校数据库课程学习者与IT入门开发者的实践报告文档，围绕“学生考勤系统”的Oracle实现展开，适合课程设计参考、数据库建模练习与项目答辩准备。压缩包共1个doc文件，约227KB，内容按背景分析、需求分析、系统功能划分、E-R模型、数据字典、表逻辑结构、表空间与建表等章节组织，并包含心得体会与参考文献。已有967人学习下载。读者可据此了解学生、任课老师、班主任、院系领导、管理员等多角色需求，梳理请假、考勤、后台管理模块的设计思路，参考从概念模型到物理表创建的完整流程，并借鉴存储过程、触发器等课程设计常见要点。
1. 一次点名点出三个问题：这套 Oracle 数据库课程设计到底要交付什么
点名这件事看着简单，做成系统就会牵出三条线：请假单交上去谁批、批完任课老师怎么知道、期末统计按谁的口径算。这份 Oracle 数据库课程设计要交付的学生考勤系统，就是把这三点一次说清：学生在线提申请并随时看进度，班主任和院系领导在系统里完成两级审批，任课老师录入出勤时系统自动带出请假结果，避免“假批了但课上仍记旷课”这种最常见的对不上账。它适合两类人：正在做数据库课设、需要一份结构完整可照搬的同学，以及想拿一个真实业务练手 Oracle 表空间、约束、视图、存储过程和触发器的开发者。整套设计的重心不在界面，而在数据怎么组织、规则怎么落在数据库端。
2. 需求与角色边界：六类用户、三大模块怎么切才不打架
学生考勤系统最容易翻车的地方不是表建不出来，而是角色没切干净——一个“查看出勤”的动作，学生看自己、班主任看本班、院系领导看本院、学校领导看全校，如果一开始不在需求阶段把可见范围定死，后面会演变成在每个查询页面里塞 if-else 的灾难。所以需求分析阶段的产出不是一段文字描述，而是一张能直接指导建表和写视图的权限边界表。
2.1 六类用户的权限边界与操作清单
角色划分按“谁产生数据、谁消费数据”来定，而不是按组织架构堆人头。学生和任课老师是数据生产者（请假单、出勤记录），班主任和院系领导是审批与校正者，学校领导是纯消费者，系统管理员负责基础数据同步。把这层关系先用表格钉住：
| 角色 | 主要操作 | 可见数据范围 | 硬约束 |
|---|---|---|---|
| 学生 | 提交请假、查看请假进度、查本人出勤 | 仅本人 | 不能改已提交的请假单，只能撤回重提 |
| 任课老师 | 录入/公布所教班级出勤 | 所教班级 | 公布后不可直接改，需走更正流程 |
| 班主任 | 审批本班请假、查看本班出勤 | 本班 | 只审批本班，不跨班 |
| 院系领导 | 审批超过三天的请假、查看本院出勤 | 本院系 | 只处理班主任已同意的长假 |
| 学校领导 | 按条件查询全校出勤 | 全校 | 只读，无任何写权限 |
| 系统管理员 | 维护院系/专业/班级/课表/用户 | 全部 | 不介入具体审批结论 |
这张表的价值在于后面每一个模块的查询条件都能从“可见数据范围”这一列直接翻译成 SQL 的 where 子句或者视图定义，不需要再重新讨论一遍。我在做这类课程设计时习惯把这张表放在需求文档最前面，答辩时评委翻到第一页就知道你想清楚了。
2.2 三大模块的职责切分与依赖顺序
按功能划分成请假、考勤、后台管理三块，但它们的依赖关系是有方向的：后台管理是地基，请假是中间层，考勤是顶层。后台管理维护院系、专业、班级、班主任指派和每学期课表，这些数据每学年都变，如果课表不能动态更新，考勤记录里的“课程”就成了死数据；请假模块产出的审批结论，又是考勤模块判定“旷课还是请假”的输入。所以建库和写代码的顺序必须是后台管理 → 请假 → 考勤，反过来做，后面一定要返工补外键。
具体到表上，这条依赖链表现为：faculty、major、classteacher、classes、student必须先于qingjia和kaoqin_record存在，因为后者要引用前者的主键。很多人写建表脚本时按文档顺序抄，结果第一句就报 ORA-00942（表或视图不存在），其实是外键指向了一张还没创建的表。这个坑在第 5 章会展开。
请假模块的业务链条也要说清楚：学生提交 → 班主任审批 → 若天数超过阈值，转院系领导审批 → 结论回写。考勤模块则是在任课老师录入出勤时，用学号 + 课程 + 日期去请假表里比对，落在请假区间内且已批准的，出勤状态记为“请假”，否则按实际点名结果记“出勤/旷课/迟到”。这条比对逻辑放在应用层还是数据库端，是个需要提前决定的设计选择，我的做法是把它做成一个可被调用的判定过程，避免每个录入入口各写一遍。
2.3 业务规则怎么提前定死：请假时长、审批状态、缺勤阈值
需求文档里最容易被忽略、又最容易在答辩时被追问的，是那些“数字型”的规则。原方案里有三条必须落到约束或代码里：请假最长不超过一个月（特殊情况另走流程）；请假超过三天需院系领导审批；某学生某课程缺勤达到三次触发取消考试资格提示。这三条如果不写死，系统就只是一堆增删改查。
审批状态用单字符编码：0等待审批、1同意、2不同意。用char(1)而不是中文串，既省空间又方便加检查约束。请假天数与审批层级的关系可以直接在插入前判断：
-- 请假单提交前的规则校验：天数决定是否需要院系领导审批 create or replace procedure submit_qingjia( p_stu_no in varchar2, p_class_id in char, p_reason in varchar2, p_start in date, p_end in date ) as v_days number(3); begin v_days := trunc(p_end) - trunc(p_start) + 1; -- 规则一：单次请假不得超过 31 天 if v_days > 31 then raise_application_error(-20001, '单次请假不得超过 31 天，请走特殊流程'); end if; insert into qingjia(id, class_id, stu_no, leave_reason, start_time, end_time, day_number, qingjia_time, class_tea_sp_status) values (seq_qingjia.nextval, p_class_id, p_stu_no, p_reason, p_start, p_end, v_days, sysdate, '0'); end; /这里trunc(p_end) - trunc(p_start) + 1是日期差再加一天，因为 Oracle 的 date 相减得到的是天数差，起止同日应当算一天，不减一就会把一天的假算成零天。raise_application_error抛出的自定义错误码建议统一放在 -20001 到 -20999 区间，避免和系统错误码冲突。序列seq_qingjia用来生成请假单主键，比在应用层算 max(id)+1 安全，后者在并发下必然重号。
提示：请假天数不要用应用层算完再传进来，放在存储过程里算，可以顺带校验起止时间是否颠倒——
p_end < p_start的情况在实际提交里出现频率远超预期。
3. 数据模型：从 E-R 图到 12 张表的逻辑结构设计
数据库课程设计的评分重心，八成落在模型设计这一章。E-R 图画得再漂亮，如果不能一步步推成带主外键和类型定义的表结构，中间就是断的。这一章要解决的是“实体怎么识别、联系怎么定基数、属性怎么落成字段”这三个连续问题。
3.1 实体与联系的识别
实体从需求里的名词捞：学生、教师、班主任、院系领导、学校领导、管理员、院系、专业、班级、课程、请假条、考勤记录，共 12 个，正好对应 12 张表。识别实体时有两个容易多算的：班主任和院系领导，看似是“教师的角色”，但他们的属性并不完全等同于教师（班主任挂专业和学院，院系领导挂学院和职称），且审批记录要单独引用其编号，所以拆成独立实体更干净。这个取舍答辩时经常被问到，理由讲清就行。
联系和基数要逐个交代：院系 1:N 专业，专业 1:N 班级，班级 1:N 学生，院系 1:N 教师；教师 M:N 课程（授课），班级 M:N 课程（开课），学生 M:N 课程（修读并产生考勤）；学生 1:N 请假条；班主任 1:N 班级（管理），院系领导 1:N 请假条（审批）。多对多的“授课”和“开课”在逻辑设计阶段会退化——本方案的做法是把课表安排在后台管理的班级课程关系里体现，考勤记录直接引用教师编号和课程编号，用一张kaoqin_record同时承载“谁在哪节课上记录了这个学生的状态”，避免了额外建三张关系表带来的连接成本。
请假条与考勤记录的关联不是外键，而是时间区间比对。这一点必须在文档里写明，否则评委会以为你漏了一个外键。理由是：请假是按时间段生效的，一节课是否落在假期内需要运行时判断，用外键反而表达不了区间关系。
3.2 数据字典的写法
数据字典不是把表结构抄一遍，而是给每个数据项一个“定义式”。我一般用固定四段式：名字、描述、定义、位置。举请假条为例：
名字：请假条信息 描述：一名学生提交的一次请假申请及其两级审批结果 定义：请假条信息 = 请假代号 + 班级代号 + 学号 + 请假原因 + 开始时间 + 结束时间 + 请假天数 + 申请时间 + 班主任编号 + 班主任审批状态 + 班主任审批时间 + 院系领导编号 + 院系领导审批状态 + 院系领导审批时间 位置：qingjia 表 约束：请假天数 = 结束时间 - 开始时间 + 1；审批状态取值 0/1/2这个格式的好处是“定义”那一行能直接对照建表语句逐字段核验，答辩时被问“你这个字段干什么用的”，照着念就是答案。12 张表逐一写完，篇幅大概两三页，是整份报告里性价比最高的部分。
3.3 逻辑结构设计与字段类型取舍
从 E-R 到表，真正要动脑的是类型选择。原方案里有几个典型取舍值得说：
编号类字段统一用char(n)而不是varchar2，因为学号、教师编号长度固定，char 在 Oracle 里定长存储，比较时不需要处理变长尾部，索引效率也稳定。姓名、请假原因这类用varchar2，长度按实际：姓名 30，请假原因 200。性别用char(2)配检查约束in ('男','女')，比用char(1)编码可读性更好，代价是多一个字节，课设规模完全无所谓。
时间字段是重点。原稿里写的是datetime，而 Oracle 没有这个类型，正确的是date（精确到秒）或timestamp。考勤时间、请假起止、审批时间全部用date就够，因为业务上不需要毫秒。这个类型错误如果带到建表脚本里，执行时直接报 ORA-00902，属于必须提前纠正的硬伤。
状态位统一char(1)，天数用number(3)（上限 999 足够），编号类主键如果是自增的用number配序列，如果是外部给定的用char。下面这张是请假表的逻辑结构，可以直接照着建：
| 字段名 | 类型 | 空 | 键/约束 | 说明 |
|---|---|---|---|---|
| id | number | 否 | 主键，序列生成 | 请假代号 |
| class_id | char(10) | 否 | 外键 → classes | 班级代号 |
| stu_no | char(10) | 否 | 外键 → student | 学生学号 |
| leave_reason | varchar2(200) | 否 | — | 请假原因 |
| start_time | date | 否 | — | 开始时间 |
| end_time | date | 否 | — | 结束时间 |
| day_number | number(3) | 否 | 1~31 | 请假天数 |
| qingjia_time | date | 否 | 默认 sysdate | 申请时间 |
| class_tea_id | char(5) | 是 | 外键 → classteacher | 班主任编号 |
| class_tea_sp_status | char(1) | 否 | 默认 '0'，0/1/2 | 班主任审批状态 |
| class_tea_sp_time | date | 是 | — | 班主任审批时间 |
| coll_leader_id | char(5) | 是 | 外键 → collegeleader | 院系领导编号 |
| coll_leader_sp_status | char(1) | 否 | 默认 '0'，0/1/2 | 院系领导审批状态 |
| coll_leader_sp_time | date | 是 | — | 院系领导审批时间 |
把“审批状态默认 0”写进表定义而不是靠程序保证，是这类系统里最省事的一步：任何插入路径忘了赋值，数据库也会兜住。
4. 物理落地：表空间规划与 12 张表的建表实现
逻辑结构定完，物理设计要回答三个问题：数据放哪、约束怎么加、建表按什么顺序。课程设计里这部分最能体现“你真的在 Oracle 上跑过”，因为报错信息会逼着你把顺序和语法搞对。
4.1 表空间规划与建表规范
单独建一个业务表空间，把课程设计的表全放进去，好处是磁盘使用情况可以通过数据字典视图直接跟踪，也避免了和系统表空间混在一起。原方案用的是字典管理表空间，语法在 10g 之后虽被本地管理表空间取代，但课设环境里执行仍然有效，写报告时说明这是字典管理即可：
-- 业务表空间：所有考勤系统对象统一存放，便于用数据字典跟踪磁盘占用 create tablespace att_data datafile '/u01/oracle/oradata/att01.dbf' size 100M default storage ( initial 512K -- 首批区大小 next 128K -- 后续区增量 minextents 2 -- 最少分配两个区，减少频繁扩展 maxextents 999 -- 上限，防止单个对象无限增长 pctincrease 0 -- 增量百分比为 0，区大小线性增长 ) online;几个参数的含义值得在报告里写一句：initial和next决定对象初始分配和后续扩展的区大小，两者设成一致或整数倍能减少碎片；pctincrease 0表示第四个区之后按next的固定值增长，而不是按百分比滚雪球，课设这种数据量下更可控。datafile路径必须是在服务器上真实存在且 Oracle 进程有写权限的目录，路径写错会直接报 ORA-01119，这是第一次建库最常见的失败点。
注意：不同环境的目录结构不一样，报告里贴出的路径要在自己的库上先确认，别照抄。
4.2 建表语句与约束写法
建表顺序按依赖链来：faculty→major→classteacher→classes→student→teacher→collegeleader→schoolleader→course→kaoqin_record→qingjia→admin。原因是外键只能指向已存在的表，顺序错了就报 ORA-00942。
另一个高频错误是外键的写法。原稿里出现过stu_class char(5) foreign key references classes(class_no)这种把列级约束和表级约束混在一起的写法，Oracle 不认，正确做法是在列定义后直接写references，或者统一放到表末尾用constraint ... foreign key ... references ...。我倾向于后者，因为约束有名字，后续排查报错时能一眼看出是哪条约束冲突：
-- 学生表：外键统一命名，便于后期定位违反约束的具体关系 create table student ( stu_no char(10) not null, stu_name varchar2(30) not null, stu_sex char(2) not null, stu_class char(10), stu_major number, stu_faculty number, constraint pk_student primary key (stu_no), constraint ck_student_sex check (stu_sex in ('男','女')), constraint fk_student_class foreign key (stu_class) references classes(class_no), constraint fk_student_major foreign key (stu_major) references major(major_id), constraint fk_student_fac foreign key (stu_faculty) references faculty(faculty_id) ) tablespace att_data;约束命名的规则我一般用“类型缩写_表名_字段名”：pk_主键、fk_外键、ck_检查、uk_唯一。这样一条 ORA-02291（违反完整约束条件）报错里带着约束名，直接就知道是哪张表的哪个外键出了问题，不用去翻脚本。
出勤记录表和请假表的建表要点在约束密度上。出勤记录里stu_status只允许几个固定值，用检查约束限制住，比在应用层判断可靠：
-- 出勤记录：状态枚举 + 教师/课程/学生三方外键 create table kaoqin_record ( kaoqin_id char(13) not null, sk_time date not null, stu_number char(10) not null, stu_status char(10) not null, teacher_no char(10) not null, course_no char(13) not null, constraint pk_kaoqin primary key (kaoqin_id), constraint ck_kaoqin_status check (stu_status in ('出勤','迟到','早退','旷课','请假')), constraint fk_kaoqin_stu foreign key (stu_number) references student(stu_no), constraint fk_kaoqin_tea foreign key (teacher_no) references teacher(tea_no), constraint fk_kaoqin_course foreign key (course_no) references course(course_no) ) tablespace att_data;stu_status用中文枚举值虽然占空间，但对课设来说可读性优先，导出报表时不用再做码表翻译。如果追求规范，可以改成char(1)编码再加一张字典表，代价是多一次连接，规模不大时没必要。
4.3 索引与外键的落地
主键会自动建唯一索引，外键列不会。考勤记录表最容易膨胀，按学号、按课程、按时间是三类主要查询，所以stu_number和course_no上建议各建一个普通索引；请假表按学生查进度、按班主任查待办，stu_no和class_tea_sp_status也需要索引：
-- 高频查询列建普通索引：按学生查考勤、按审批状态查待办请假 create index idx_kaoqin_stu on kaoqin_record(stu_number) tablespace att_data; create index idx_kaoqin_course on kaoqin_record(course_no) tablespace att_data; create index idx_qingjia_stu on qingjia(stu_no) tablespace att_data; create index idx_qingjia_sp on qingjia(class_tea_sp_status) tablespace att_data;这里有个课设里常被忽略的点：外键列建索引不只是为了查得快，还为了避免删除父表记录时的锁问题——父表删一行，子表没有索引就要全表扫描找引用行，小数据量看不出来，答辩时被问“为什么外键要建索引”答不上来就尴尬了。
5. 数据库端编程：存储过程、视图、触发器的实现与常见问题排查
这一章是整个课程设计里区分度最高的部分。会建表的人很多，能把统计逻辑、权限隔离、阈值提醒下沉到数据库端的人不多。原方案的心得里也提到，关键功能用存储过程和函数封装在数据库端，这个判断是对的，但具体写法上有几处必须纠正。
5.1 存储过程：把统计逻辑收进数据库
需求是“统计某学生某门课程的缺勤次数”，这个查询被多个入口调用（学生自查、班主任看班、任课老师看课），放在数据库端只维护一份。原稿的过程体有几个典型错误：参数列表里total_times outnumber缺空格、赋值用了=而不是 PL/SQL 的:=、统计时没有区分状态。修正后：
create or replace procedure get_absence( p_stu_no in varchar2, -- 学生学号 p_course_no in varchar2, -- 课程编号 p_total out number -- 返回：该生该课程的旷课次数 ) as begin select count(*) into p_total from kaoqin_record where stu_number = p_stu_no and course_no = p_course_no and stu_status = '旷课'; -- 只统计旷课，请假不算缺勤 end; /三点说明：out参数前必须有空格，outnumber会被当成一个未声明的类型名，编译时报 PLS-00103；PL/SQL 里的赋值是:=，用=会报语法错误；最重要的是加了stu_status = '旷课'这个条件——原稿统计的是全部记录，等于把出勤也数进去了，这种逻辑错误不会报错，只会给出一个看起来合理但完全错误的数字，属于最危险的一类 bug。调用方式在 SQL*Plus 里是var n number; exec get_absence('学号','课程号',:n); print n;。
提示：存储过程里尽量用
%type或明确的类型，不要依赖隐式转换；p_stu_no声明成varchar2而表里是char(10)时，Oracle 会做隐式转换，索引可能失效，规模小无所谓，但答辩问起来要能解释。
5.2 视图：按院系做行级隔离
院系领导只能看本院学生，这个“只能”如果靠应用层拼 where，一旦某个入口忘了拼就是数据越权。用视图把这层过滤固化下来，是最省心的做法。原方案是给每个院系建一个硬编码视图，思路正确但扩展性差——新增一个院系就要新建一个视图。更通用的写法是建一个带院系列的视图，由应用层或角色权限再过滤：
-- 通用考勤视图：携带院系编号，配合应用层条件实现行级隔离 create or replace view v_kaoqin_faculty as select r.kaoqin_id, r.sk_time, r.stu_number, r.stu_status, r.teacher_no, r.course_no, s.stu_faculty from kaoqin_record r join student s on s.stu_no = r.stu_number;如果课设要求的是“视图内直接隔离”，那就按院系编号建独立视图，加上with check option保证通过视图做 DML 时也不能越界：
-- 单个院系的隔离视图：编号 5 代表某个院系，实际使用时替换 create or replace view v_kaoqin_fac5 as select r.kaoqin_id, r.sk_time, r.stu_number, r.stu_status, r.teacher_no, r.course_no from kaoqin_record r join student s on s.stu_no = r.stu_number where s.stu_faculty = 5 with check option;两种做法各有取舍：通用视图灵活，隔离靠上层；专用视图隔离彻底，但院系多了维护成本高。课设报告里把两种都写出来并说明选择理由，比只贴一种更能体现设计思考。
5.3 触发器：缺勤阈值的即时提示
“某学生某课程缺勤超过三次提示取消考试资格”这条规则，用行级触发器在插入出勤记录后判断最直接：
create or replace trigger trg_kaoqin_alert after insert on kaoqin_record for each row declare v_times number; v_limit constant number := 3; -- 阈值：三次旷课触发提醒 begin if :new.stu_status = '旷课' then select count(*) into v_times from kaoqin_record where stu_number = :new.stu_number and course_no = :new.course_no and stu_status = '旷课'; if v_times >= v_limit then dbms_output.put_line('学号 ' || :new.stu_number || ' 在课程 ' || :new.course_no || ' 累计旷课 ' || v_times || ' 次，取消考试资格'); end if; end if; end; /for each row是行级触发器的关键，少了它整条语句只触发一次，:new也用不了。dbms_output只在当前会话有效，也就是说任课老师在同一个 SQL*Plus 窗口里录入能看到提示，换个窗口就看不到——这是课设演示时最容易翻车的点，正确做法是把提示写进一张预警表，前端去查未读预警，dbms_output只作为调试手段。这个区别在报告里点一句，能明显拉开和其他人的差距。
5.4 常见问题排查：五个最容易翻车的点
现象一：建表脚本第一条就报 ORA-00942，表或视图不存在。原因是外键指向的表还没建，脚本按文档章节顺序抄，而文档顺序不等于依赖顺序。解决办法是按 4.2 给的依赖链重排，先建被引用的父表；实在要乱序，就先建所有表不带外键，最后用alter table ... add constraint统一补。
现象二：建表报 ORA-00902 无效数据类型。十有八九是写了datetime。Oracle 的日期时间类型只有date和timestamp，date已包含到秒的时间部分，课设场景统一用date。改完记得同步改数据字典里的类型描述，别只改代码。
现象三：存储过程能编译但结果永远是 0 或明显偏大。先查 where 条件是不是漏了状态过滤，再查参数名和列名是否撞了——PL/SQL 里如果形参名和列名同名（比如形参也叫stu_number），SQL 语句里会优先解析成列名，导致条件恒真。规避办法是形参统一加p_前缀，这是我从一次排查里学到的习惯。
现象四：触发器编译通过但没有任何输出。除了dbms_output的会话限制，还要确认serveroutput是否打开（set serveroutput on），以及插入的记录状态是否真的等于'旷课'——中文枚举值最容易因为字符集不一致存进去变成问号，此时等值比较永远不成立。检查方式是select dump(stu_status) from kaoqin_record where rownum = 1;，看字节是否正常。
现象五：删除学生或教师时报 ORA-02292 违反完整约束。这是外键在没有on delete cascade时的正常保护，不是 bug。课设里不要图省事加级联删除，出勤和请假是历史数据，正确做法是先删子表记录或改用状态位标记失效，报告里把这一点写成“数据保留策略”，反而是加分项。
6. 交付验收：把课程设计跑成一场能自证的答辩演示
课设的最后一步不是写完报告，而是能在评委面前把系统跑通、把设计讲圆。我的做法是准备一份自查清单加一段固定顺序的演示脚本，两者配合，基本不会在现场卡壳。
自查清单按“能不能被验证”来列，每一条都对应一个可执行的检查动作：
| 检查项 | 合格标准 | 验证方式 |
|---|---|---|
| 建库脚本可重跑 | 空库执行一遍无报错 | 删表后重跑全部 DDL |
| 外键完整性 | 插入非法学号的考勤记录被拒 | 手动执行一条越界 insert |
| 请假规则 | 提交 40 天请假被拒 | 调用 submit_qingjia 传超长区间 |
| 审批流转 | 3 天以内不生成院系领导待办 | 查 qingjia 的审批状态字段 |
| 统计口径 | 请假不计入旷课次数 | 造一条请假记录后调 get_absence |
| 视图隔离 | 院系视图查不到其他院系数据 | 换院系编号对比结果集 |
演示顺序固定为五步：先展示表空间和 12 张表的表结构（证明物理设计落地），再插入一组跨院系、跨班级的测试数据（证明约束生效），接着走一遍学生提交 → 班主任审批 → 院系领导审批的完整请假流（证明业务闭环），然后录入一条旷课触发出勤阈值提醒（证明数据库端编程有效），最后用视图切到院系视角查数据（证明权限隔离）。这五步走完，报告的六个章节其实已经全部演示过了，不需要额外解释。
答辩问题提前准备三个最可能被问的：为什么统计逻辑放存储过程而不是应用层——答复用和一致性，多处调用只维护一份口径；为什么请假的审批状态用编码不用中文——答约束可枚举、比较效率高；视图隔离和权限控制有什么区别——答视图是数据可见范围，权限是操作许可，两者互补不能互替。
最后说一个我自己的习惯。早些年做这类设计，我总是先把表全建完再回头补外键，结果每次都要重跑一遍脚本，报错信息翻来覆去就那几条。从那以后我每次建库前都强制先画一张依赖顺序图，把父表排在前面，DDL 脚本按图分段、每段末尾加一句注释标明“下一段依赖本段”，跑通一次再写正文。这套流程后来用在好几个项目上都没出过建表顺序的岔子。希望帮到你。
本文还有配套的精品资源，点击获取
