SchoolDB教务数据库4张核心表DDL设计全解析

看到"仅有结构"这四个字，懂行的人应该知道这意味着什么——这不是一份带着演示数据的脚本，而是一份干净到可以直接拿来建表的DDL总览。SchoolDB这个命名也很直白，就是典型的学校教务管理系统核心库。今天我把这4张表的DDL语句完整梳理一遍，说清楚每个字段为什么这么定、约束为什么这么加、建表顺序为什么不能乱，以及实际执行时容易踩到的那些坑。不管你是刚学数据库设计的学生，还是第一次接手学校类业务系统的开发者，这份建表脚本和里面的拆解思路都能直接参考。

1. 整体设计：SchoolDB为什么是这4张表

1.1 教务场景的实体拆分逻辑：从业务到表

学校教务系统无论做得多复杂，最核心的业务闭环就是三个动作：排课、选课、记录成绩。这个闭环背后涉及的实体其实非常清晰：得有人来上课，这是学生；得有课可以选，这是课程；得有人教这门课，这是教师；学生选了课、这门课最后要出成绩，这是选课记录。

所以4张表的设计思路是这样的：

• students：学生表，存学生基础信息。
• teachers：教师表，存教师基础信息。
• courses：课程表，存课程基础信息，同时记录这门课由哪位老师教。
• enrollments：选课表，存学生选了哪门课、最终考了多少分。

很多初学者容易纠结：选课记录算不算独立业务？成绩能不能直接挂在课程表里？答案是不能。因为一个学生和一门课是多对多关系，一个学生可以选多门课，一门课可以被多个学生选。多对多关系在关系型数据库里必须拆成一张中间表来落地。enrollments这张表就是那个"中间人"，它同时引用学生和课程两张表，顺便承载了成绩字段。

1.2 表与表之间的关系：谁引用谁、为什么

四张表的关系非常清晰，但有一处容易搞混：课程表里直接放了teacher_id，这意味着一门课对应一个老师，是典型的一对多关系。为什么不在选课表里放teacher_id？因为一门课在某个学期通常就是一位老师负责，课程和老师的绑定关系是排课时确定的，和谁选了这门课无关。如果一门课未来可能由多位老师共同授课，再单独拆一张"课程教师关系表"也不迟，但在目前这个简洁版本里，courses.teacher_id是合理且够用的。

外键方向也要注意：外键永远跟在"多"的这一侧。学生和选课是1:N，所以外键在enrollments.student_id；课程和选课是1:N，所以外键在enrollments.course_id；教师和课程是1:N，所以外键在courses.teacher_id。

主键统一用INT UNSIGNED类型，内部自增ID不暴露业务语义。同时每张业务表都保留一个业务唯一键，比如学生表有student_no（学号）、教师表有teacher_no（工号）、课程表有course_code（课程代码）。这样做的逻辑是：数据库内部主键随便怎么变，对外业务的唯一标识不受影响，后续接其他系统对接时也方便。

2. 四张表的DDL语句与字段设计解析

这一节直接上干货，每一张表我会给出完整的DDL语句，再逐字段解释设计意图。执行顺序我放在后面第3章专门讲，这里先理解结构本身。

2.1 学生表（students）的DDL与字段取舍

CREATE TABLE students ( student_id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '学生内部ID，自增主键', student_no VARCHAR(20) NOT NULL COMMENT '学号，业务唯一标识', name VARCHAR(50) NOT NULL COMMENT '姓名', gender TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '性别：0未知 1男 2女', birth_date DATE DEFAULT NULL COMMENT '出生日期', phone VARCHAR(20) DEFAULT NULL COMMENT '手机号', email VARCHAR(100) DEFAULT NULL COMMENT '邮箱', major VARCHAR(100) NOT NULL COMMENT '专业', enrollment_date DATE NOT NULL COMMENT '入学日期', status TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT '状态：1在读 2休学 3毕业 4退学', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (student_id), UNIQUE KEY uk_student_no (student_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='学生信息表';

这里有几个字段拿捏得很讲究：

gender用TINYINT而不是CHAR(1)存"男/女"。用整数存性别的好处是避免字符串编码问题，而且扩展语义方便，比如未来要存"保密"或"其他"，直接加数字枚举值就行。坏处是应用层必须维护一份枚举字典，否则后来的人看不懂0、1、2是什么意思。所以我强烈建议：每个字段的COMMENT里写清楚取值含义，这比在文档中心写说明管用得多，因为在绝大多数项目里，代码注释会过期，但表结构的COMMENT会一直跟着字段走。

student_no和student_id是两套标识。刚接触数据库的同学常有一个疑问：直接用student_no当主键不行吗？当然行，但业务主键有一个隐患——它可能在某个奇葩场景下被修改。比如学校搞过一次学号大清洗，所有学生学号重编号，如果你拿学号当主键，所有引用它的外键都要跟着改，级联更新跑一遍可以说相当酸爽。内部自增主键是稳定不变的，业务上随便改，这个设计思路值得学习。

status字段是逻辑删除的雏形。教务场景里学生毕业、休学、退学是常态，如果把记录物理删除，选课表的成绩历史就断了。用状态字段标记，既保留了全量历史，又能在查询里用WHERE status = 1过滤出在读学生。这个小技巧很多教科书不讲，但在真实业务系统里几乎必不可少。

2.2 教师表（teachers）的DDL与基础信息规划

CREATE TABLE teachers ( teacher_id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '教师内部ID，自增主键', teacher_no VARCHAR(20) NOT NULL COMMENT '工号，业务唯一标识', name VARCHAR(50) NOT NULL COMMENT '姓名', title VARCHAR(50) DEFAULT NULL COMMENT '职称：助教/讲师/副教授/教授', department VARCHAR(100) NOT NULL COMMENT '所属院系', phone VARCHAR(20) DEFAULT NULL COMMENT '手机号', email VARCHAR(100) DEFAULT NULL COMMENT '邮箱', hire_date DATE DEFAULT NULL COMMENT '入职日期', status TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT '状态：1在职 2离职 3休假', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (teacher_id), UNIQUE KEY uk_teacher_no (teacher_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='教师信息表';

职称title字段存的是字符串而不是字典ID。这里其实是故意做的一个权衡：当整个库只有4张表时，为了一个职称再去建一张title_dict字典表，查询要JOIN两次，成本大于收益。字符串字段在业务初期足够用，等未来职称种类多到需要维护排序和权限时，再拆字典表也不迟。这个思路就是"最小化设计"，先满足当前需求，不为想象中的未来过度设计。

department同样存的是院系名称。有人会说，应该存部门ID才对，不然院系改名了怎么办？这个质疑有道理，但逻辑上院系名称和学生的major一样，在演示或学习项目中直接冗余存储问题不大。如果你觉得不能接受，完全可以把department提升为院系表，这里保留名称只是为了让DDL保持简洁、让初学者能一眼看明白表之间的关系。

2.3 课程表（courses）的DDL与学分设计

CREATE TABLE courses ( course_id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '课程内部ID，自增主键', course_code VARCHAR(20) NOT NULL COMMENT '课程代码，如CS101', course_name VARCHAR(100) NOT NULL COMMENT '课程名称', credit DECIMAL(3,1) NOT NULL DEFAULT 2.0 COMMENT '学分，支持0.5学分', teacher_id INT UNSIGNED DEFAULT NULL COMMENT '授课教师ID，删除教师时置空', total_hours INT UNSIGNED DEFAULT NULL COMMENT '总学时', semester VARCHAR(20) NOT NULL COMMENT '开课学期，如2025-2026-1', capacity INT UNSIGNED NOT NULL DEFAULT 60 COMMENT '选课容量', status TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT '状态：1可选 0不可选', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (course_id), UNIQUE KEY uk_course_code (course_code), KEY idx_teacher_id (teacher_id), CONSTRAINT fk_courses_teacher FOREIGN KEY (teacher_id) REFERENCES teachers (teacher_id) ON DELETE SET NULL ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='课程信息表';

credit学分用的是DECIMAL(3,1)，而不是INT。原因是很多学校存在0.5学分、1.5学分这种非整数课程。用DECIMAL(3,1)的意思是总长度3位、小数1位，最大99.9学分，正常课程绝对够用。如果用FLOAT或者DOUBLE存学分，一旦涉及分数汇总，浮点误差就会开始作妖。课程表里凡是涉及"多少分、多少量"的字段，优先考虑DECIMAL，这是花过钱买过的教训。

teacher_id字段是外键，但允许为NULL，删除教师时ON DELETE SET NULL。这个细节值得展开：如果一个教师离职了，课程表里他的课不应该跟着一起删除，正确的做法是将课程的teacher_id置为NULL，保留课程本身，让教务人员后续重新安排教师。这里外键的级联策略选的是SET NULL，就比RESTRICT或CASCADE都合适。CASCADE会让课程跟着老师一起被删掉，那可就出大事了；RESTRICT则是老师没删掉课就删不了人，也不灵活。

course_code加了唯一键。课程代码一般由院系缩写和数字组成，比如CS101、MATH201，这种代码在排课时是要打印在课表上给全校学生看的，重复了就会造成选课混乱，所以必须唯一。

2.4 选课表（enrollments）的DDL与多对多关系落地

CREATE TABLE enrollments ( enrollment_id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '选课记录ID，自增主键', student_id INT UNSIGNED NOT NULL COMMENT '学生ID', course_id INT UNSIGNED NOT NULL COMMENT '课程ID', score DECIMAL(5,2) DEFAULT NULL COMMENT '最终成绩，百分制', semester VARCHAR(20) NOT NULL COMMENT '选课学期，如2025-2026-1', selected_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '选课时间', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (enrollment_id), UNIQUE KEY uk_student_course (student_id, course_id), KEY idx_course_id (course_id), CONSTRAINT fk_enroll_student FOREIGN KEY (student_id) REFERENCES students (student_id) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT fk_enroll_course FOREIGN KEY (course_id) REFERENCES courses (course_id) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='选课记录表';

这张表是整个SchoolDB的核心。成绩字段score直接放在选课记录里，是因为成绩天然依附于"某学生选了某门课"这一条记录产生，不需要单独再建一张成绩表，这是教务系统里最常见的合并写法。成绩用DECIMAL(5,2)存百分制，能精确到小数点后两位，比如89.50分，缓冲区也够大。

uk_student_course联合唯一键是这个表的灵魂。它保证同一个学生在同一门课里只能有一条选课记录，从数据库层面砍掉了重复选课的可能性。很多项目在应用层写各种判断来防止重复选课，但数据库的唯一约束才是最后一道、也是最可靠的一道防线。这个约束在你写导入脚本时要特别注意，一旦违反会直接报Duplicate entry错误。

外键的级联策略这里用了CASCADE，和课程表里的SET NULL形成对比。当学生被删除时，他的选课记录必须一并删除，因为没有学生了你还留着选课记录，那条记录就成了"孤儿数据"，查成绩时JOIN不上学生，会造成各种诡异现象。课程同理，课程被删了，对应的选课记录也没必要保留。所以选课表对两张父表全部用ON DELETE CASCADE，逻辑上是自洽的。

3. 建库建表实操：执行顺序与参数选择

3.1 建库语句与字符集/排序规则的选择

在创建4张表之前，先要把数据库本身建好。我是这样写的：

CREATE DATABASE IF NOT EXISTS SchoolDB DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_unicode_ci;

utf8mb4是MySQL里最推荐的字符集，核心原因有两点：第一，它兼容全部Unicode字符，包括emoji表情，而utf8在MySQL里是utf8mb3的别名，只支持到基础多语言平面，遇到特殊字符会直接报错或者存成乱码；第二，在今天的业务系统里，用户输入的内容千奇百怪，一个表情符号、生僻字，都可能成为数据写入的定时炸弹。字符集用utf8mb4是最省心的选择。

排序规则collation这里选了utf8mb4_unicode_ci。它和utf8mb4_general_ci的区别在于：前者基于Unicode标准排序算法，对多语言字符的排序更准确，代价是性能略低一点；后者排序逻辑更简化、速度稍快，但在处理中文和特殊字符时偶尔会出现匪夷所思的排序结果。现在的服务器性能早就不是瓶颈了，排序规则优先选unicode_ci。

注意建库时如果不写COLLATE，MySQL会按默认配置走。如果后面建表时又单独指定了COLLATE，那库级和表级可能不一致。这种不一致在平时看不出问题，等到某个字段要做JOIN关联或比较时，就可能报出"Illegal mix of collations"错误。我的建议是：库、表、字段三层统一用utf8mb4_unicode_ci，宁可冗余写清楚，不要省这几行字。

3.2 存储引擎与自增主键的考虑

DDL里每张表都明确写了ENGINE=InnoDB，这不是随便写写的。InnoDB是MySQL默认的存储引擎，支持事务、行级锁、崩溃恢复、外键约束，这四个特性对SchoolDB这种业务系统来说缺一不可。如果你想省事把引擎那行删掉，数据库确实也会用默认引擎建表，但显式写出来可以让看脚本的人一目了然：这张表是事务安全的，是有外键约束的。

自增主键AUTO_INCREMENT也有讲究。student_id、teacher_id、course_id、enrollment_id都是INT UNSIGNED，最大值可以到42亿多，对学校这种规模的应用来说绰绰有余。但有两个小细节容易被忽略。

第一，INT UNSIGNED和INT SIGNED在MySQL里是两个不同的类型。外键关联时，如果父表主键是INT UNSIGNED，子表外键必须也是INT UNSIGNED，否则建外键约束会直接报错。这个坑我在第4章会详细讲。第二，如果未来数据量真的大到42亿不够用，ALTER TABLE把INT改成BIGINT就行，但前提是关联表的外键类型也要同步改，字段类型的统一性从设计第一天就要想好。

3.3 从零执行DDL的完整流程演示

建完库之后，4张表的执行顺序是有讲究的。因为courses表的外键指向teachers，enrollments表的外键指向students和courses，所以正确顺序是：

1. 先建teachers
2. 再建students
3. 再建courses
4. 最后建enrollments

反过来执行会直接报错：Cannot add foreign key constraint，原因是被引用的表还不存在。虽然MySQL也允许你后补外键，但先建父表再建子表是最稳妥的执行方式，尤其当你面对一段完整初始化脚本时，顺序就是脚本可靠性的第一道保证。

我习惯的执行流程是这样的：先用一条命令执行建库语句，然后USE SchoolDB，再按顺序执行4张表的CREATE语句。每执行完一张表，我习惯随手验证一下：

USE SchoolDB; SHOW TABLES; DESC students;

SHOW TABLES看整体，DESC看字段细节。如果表建得比较多、想确认外键是不是建对了，可以执行：

SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'SchoolDB';

这一条SQL能把四张表所有的外键关系全部列出来，比翻建表语句快得多。实际工作里，我每次建完外键都会跑一次这个查询，确认引用方向没有搞反。

最后提醒一句：这份DDL只是"仅有结构"，建完库之后是没有任何数据的。如果你想验证后续的插入、查询逻辑能跑通，可以手动INSERT几条测试数据，但注意插入顺序也要遵守外键依赖：先插学生和教师，再插课程，最后插选课记录。

4. 常见问题与排查技巧实录

建表语句看着简单，真放到不同环境里执行，报错的花样其实不少。我把这几年实际踩过、帮别人排查过的典型问题整理成了一张速查表，后面再挑几个重点展开。

4.1 外键约束导致建表失败：三个高频原因

我一个一个说。最常见的"foreign key constraint fails"分三种情况。

第一种就是顺序错了。courses表还没建好，就先尝试建一张引用courses的enrollments表，数据库找不到被引用的表，直接罢工。解决方法是回到我第3章说的执行顺序。

第二种是字段类型不匹配。父表主键是INT UNSIGNED，子表外键写成了INT，表面看只差一个UNSIGNED字段，但MySQL的外键检查就是过不去。哪怕父表主键是BIGINT，子表外键是INT，也不行。所有外键关联的字段，类型必须完全一致，一个字节都不能差。

第三种是被引用的字段上没有索引。MySQL有个隐藏规则：被引用的字段必须是有索引的。如果父表的teacher_id不是主键也不是唯一键，也没有普通索引，子表在创建外键时就会报错。不过我们这几张表里，被引用字段全都是主键，天然满足条件。等你以后自己设计别的表时，如果给一个"非主键字段"加外键，就要先给那个字段加上索引。

排查这类问题最快的办法是查看MySQL的详细错误信息：

SHOW ENGINE INNODB STATUS\G

在LATEST FOREIGN KEY ERROR这一段里，MySQL会告诉你具体是哪个字段找不到、哪个引用对不上，信息非常直白。

4.2 类型不匹配与隐式转换的隐患

外键报错是最容易发现的类型问题，但还有一种类型问题更隐蔽：字段类型不一致时，MySQL有时候不会报错，而是走隐式转换，结果就是性能下降加索引失效。

举个最典型的例子：如果student_id在设计时用INT，但某张表的student_id不小心定义成了VARCHAR，两个表JOIN关联时，MySQL必须把VARCHAR转成数字再比较，这条SQL的索引就用不上了，数据量一上来就是慢查询。更麻烦的是，如果VARCHAR里混了空格或者非数字字符，转换结果会出乎意料。

所以我在设计表结构时，会有一条强制约束：所有关联字段，类型必须一字不差地复制父表定义。这条规则应该写进团队的建表规范里，而不是靠每个人细心去保证。SchoolDB这4张表里所有外键字段我都保持了一致，就是这个道理。

4.3 字符集不一致的暗坑

字符集的问题在初学阶段基本碰不到，等到你开始做多环境部署时，就会撞得头破血流。

最常见的一幕：开发环境一切正常，到了测试环境或者生产环境，联合查询报出Illegal mix of collations (utf8mb4_unicode_ci,IMPLICIT) and (utf8mb4_general_ci,IMPLICIT) for operation '='。原因就是库或者表在建的时候用了不同的排序规则。虽然我们DDL里统一指定了utf8mb4_unicode_ci，但mysql服务器的默认配置可能是utf8mb4_general_ci。如果哪张表建的时候偷懒没写COLLATE，那它就会继承数据库级别的配置，一旦和其他表JOIN，就有概率翻车。

排查方法也很简单，直接查这个：

SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'SchoolDB';

输出的4行结果应该是一个统一的collation，如果有任何一行不一样，立刻用ALTER TABLE把它改过来。我见过太多"在我的电脑上好好的"的翻车案例，起因都是这个。

字符集还有另一个隐藏问题：utf8mb4每个字符最多占用4字节，MySQL索引最大长度不能超过767字节（旧版本）或3072字节（新版本）。如果你给一个VARCHAR(255)的字段建立唯一索引，在utf8mb4下会瞬间顶到1020字节，碰上线就报"Specified key was too long"。所以设计字段长度时不能脑子一热就写255，课程代码、学号这类字段控制在20-50字符以内，既满足业务，又给索引留足空间。

4.4 命名规范与后续维护成本

命名问题不会让系统立刻报错，但它会持续增加维护成本。比如student_id、stu_id、sid三种名字出现在同一个项目里，谁看谁崩溃。

我自己在命名上坚持三条原则。第一，表名统一用复数，students、courses，避免单复数混乱，SQL读起来也自然。第二，所有字段名以业务含义为主，不要搞缩写谜语。字段名就叫student_id，不要叫sid，后期维护的人不需要查字典就能看懂。第三，每个字段必须写COMMENT。这个习惯看起来啰嗦，但能救命，尤其是gender这种用数字编码的字段，没有COMMENT的情况下，三个月后连写代码的人自己都想不起来0和1分别代表什么。

还有一点关于时间字段。created_at和updated_at几乎是每张表必备的"审计字段"，建表时一次性写好，后面省掉无数"这数据什么时候加的"这种问题。updated_at用的ON UPDATE CURRENT_TIMESTAMP会自动在每次UPDATE时刷新时间戳，不用在应用层手动维护。

5. 这套表结构的扩展与演进方向

5.1 索引与查询优化：从能用到好用

4张表建好之后，日常查询基本都能跑，但索引设计还有优化空间。以选课表为例，唯一键uk_student_course(student_id, course_id)已经覆盖了"查某学生选了哪些课"的场景。如果想反过来查"某门课被哪些学生选了"，这个唯一键就用不上了，需要单独给course_id建普通索引，我在DDL里已经加了idx_course_id。

复合索引的字段顺序也有讲究。如果高频查询是"查某学期某学生的选课和成绩"，可以把索引设计成(student_id, semester)。如果高频查询是"查某门课在某个学期的选课人数"，那应该设计成(course_id, semester)。索引顺序的调整对查询性能影响巨大，但这要结合真实业务数据来分析，光靠拍脑袋没意义。我的建议是：先用EXPLAIN看执行计划，再根据慢查询日志决定加什么索引，不要一开始设计一堆索引拖慢写入。

5.2 表结构变更的平滑迁移：加字段与改类型

SchoolDB真到上线运营阶段，一定会面对结构变更。比如学生表要加一个"户籍所在地"字段，执行：

ALTER TABLE students ADD COLUMN hometown VARCHAR(100) DEFAULT NULL COMMENT '户籍所在地' AFTER email;

注意AFTER email这个位置控制，新字段不会跑到表末尾，而是在指定字段后面，对某些依赖列顺序的导出工具有一定友好度。改字段类型就要更谨慎，比如把phone从VARCHAR(20)改成VARCHAR(30)，如果目标表里有超长数据，ALTER会直接失败。这种变更最好的办法是先在测试库跑一遍，再上生产环境。

如果一张表的数据量上了百万级，ALTER TABLE在大表上会锁表，直接影响业务。这时可以考虑用在线DDL工具，或者借助数据库的在线变更能力。但这些都是后话，SchoolDB这种级别的表量，直接ALTER问题不大。

5.3 从4张表到完整教务系统的扩展路径

这套结构是教务系统的地基，地基之上要盖多少层楼，取决于业务规模。如果你未来要把它扩展成完整的教务平台，有几个方向绕不开。

第一，院系和班级需要独立建表。department直接存在courses和teachers里，短期能撑，但院系一旦要维护编制人数、负责人、办公地点，就必须拆成departments表。班级同理，学生表里加一个class_id外键，班会、班主任这类需求就都能落地了。

第二，教室资源管理要单独设计。courses表里没有room字段，排课要解决"某时间某教室不被占用"，需要一个教室维度的时间表，或者一个排课时间段表。这是一个全新的模型，四张表的框架已经不够用。

第三，权限和账号体系。学生和教师登录系统需要账号密码、角色权限，这就要引入users表、roles表、user_roles表，那又是另一套经典的RBAC模型了。

但不管系统怎么扩展，最底层的"学生-课程-教师-选课"这四张表的关系骨架是稳定不变的。这也是为什么我特别推荐初学者从这套结构入手的原因：它足够简单，但包含了数据库设计里最核心的三板斧——主键设计、外键约束、多对多关系拆分。把这四张表吃透，后面再学任何业务系统的表结构设计，思路都是一通百通的。

最后分享一个我自己的习惯：拿到任何需要建表的任务，先不要急着打字，拿张纸把实体和关系画一遍。你在纸上理清楚的"谁引用谁""谁先创建"，比任何开发工具都可靠。SchoolDB这种看似简单的四张表，其实已经把关系型数据库的精华都装进去了。建表的DDL只是开始，真正值钱的是你理解了它背后的每一处取舍和约束。