SchoolDB这个项目名听起来平平无奇，但它是几乎所有学校类业务系统都绕不开的数据库地基。无论你是要搭一个带选课功能的教务Demo，还是准备给真实学校做信息管理后台，最底层都需要一组结构干净的表来撑住。下面直接给出SchoolDB对应的4张核心表的DDL语句——仅有结构，不塞初始数据，不带存储过程，把注意力全部放在字段、类型、约束和索引这些真正决定数据质量的地方。
很多刚接触数据库设计的同学，第一次建表通常很随意：字段名用拼音缩写、主键要么每个表都塞一个自增ID，要么干脆把业务编号直接设成主键，等到后面写联表查询和统计报表时才发现各种别扭。如果你正准备从零搭一个学校相关系统的数据层，这4张表的设计思路和完整DDL可以直接拿来用，也可以顺着这套思路扩展出班级、院系、考勤、教材等更多表。
1. 为什么是这4张表：SchoolDB的最小闭环设计
1.1 从业务闭环反推表清单
如果你去问一个没有经验的新人：学校管理系统需要哪些表？他大概率会给你列出一串名字——班级表、院系表、专业表、宿舍表、教材表、教室表……名单能写满一张A4纸。但这个思路有问题，它从"学校有什么组织"出发，而不是从"学校每天在完成什么业务"出发。
把学校的核心业务压缩到最小，其实就是一条链路：学生入学后，教师开出若干门课，学生选择课程，教师期末打分。这条链路上每个环节都必须落数据，于是至少有四类实体绕不开：学生、教师、课程、选课结果。这就是SchoolDB第一版锁定student、teacher、course、course_selection四张表的根本原因。
设计数据库时，表的数量不是越多越好。多一张表就意味着多一组主外键关系、多一串联表查询的JOIN条件、多一份数据一致性要维护。第一版让业务闭环能完整跑起来，是最高优先级。
1.2 表数量为什么锁定为4张
有人会问：既然学生表里要存专业，为什么不单独建一张专业表？教师表里要存院系，为什么不建院系表？我的答案是：第一版先用"冗余字段"顶着，不要急于拆表。专业和院系在成熟的教务系统里确实应该独立成表，但那是在数据规模上来、统计口径变多之后才需要做的事。初期把它们当作普通文本字段挂在student和teacher身上，完全够用。
这样锁定4张表还有一个实际好处：数据模型好讲清楚。我做这个SchoolDB项目时，见过不少为了"建模完整"建了十几张表的方案，结果外键关系拉出来密密麻麻，连设计者自己都要拿纸画半天。4张表的学习成本低很多，每张表的职责一眼能看懂，后续加表也只是往骨架的缝隙里插，不影响主干。
2. 学生表DDL：学号与主键的经典之争
2.1 完整DDL语句
学生表是整个SchoolDB里引用最频繁的表，它的结构定下来，后面选课表的逻辑才会顺。下面是MySQL版本的学生表DDL，只包含结构，不含任何初始化数据：
CREATE TABLE student ( id BIGINT UNSIGNED AUTO_INCREMENT COMMENT '主键', student_no VARCHAR(20) NOT NULL COMMENT '学号', name VARCHAR(64) 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(128) DEFAULT NULL COMMENT '邮箱', major VARCHAR(64) DEFAULT NULL COMMENT '专业名称（冗余字段）', enroll_year SMALLINT UNSIGNED DEFAULT NULL COMMENT '入学年份', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), UNIQUE KEY uk_student_no (student_no), KEY idx_major (major), KEY idx_enroll_year (enroll_year) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='学生表';逐个字段说一下为什么会这样设计。
id用BIGINT UNSIGNED AUTO_INCREMENT，不用INT。学校系统的数据量初期可能只有几千行，但一张学生表会长时间留在线上，等到系统接入多个年级、多个校区后，INT的上限2亿多看似够用，却架不住某些导入操作把ID分段预留、甚至出现回填负数的情况。BIGINT留出的余量更大，而且从习惯上讲，后面做分库分表时BIGINT也是主流。
student_no是学号，必须用VARCHAR(20)，不能用数字类型。学号这个字段在现实里经常出现前导零，比如"20250101"开头的编号，如果用INT存储，前导零会被吃掉，再想找回原值只能靠补零逻辑。如果未来还要兼容带字母后缀的学号，更是只能靠VARCHAR。
name用VARCHAR(64)而不是VARCHAR(32)，是给中文姓名留余量。虽然绝大多数姓名不超过四个字，但历史数据里确实会出现长复姓和少数民族姓名，数据库设计宁可多给不要少给，代价只是每行多几个字节。
gender用TINYINT UNSIGNED，不用ENUM('男','女')。ENUM看起来直观，但它把枚举值写死在表定义里，业务里一旦要新增"未知"或"保密"以外的选项，必须ALTER TABLE，而TINYINT靠应用层解释数字含义，调整成本低得多。也不要用INT，一个0/1/2的字段占4个字节太浪费。
2.2 为什么学号不设为主键
这里几乎是学生表设计里最有争议的一点。很多新人会直接写PRIMARY KEY (student_no)，理由是"学号天生唯一、天然非空、查询时最常用"。这个逻辑在纸面上成立，但放到真实业务场景里会出问题。
主键有三条硬性要求：非空、唯一、稳定。student_no满足前两条，但"稳定"这条很可能被现实击穿。举个例子，学校之间合并、学籍系统迁移时，旧学号可能被回收再分配给新学生，同一个学号在校史里对应过两个不同的人。又比如历史脏数据里存在重复学号，导入时为了去重，不得不给后导入的人改学号。这些情况下，学号一旦变化，所有引用它的子表都要跟着改，代价是灾难级的。
所以正确做法是引入与业务无关的代理主键id，学号用UNIQUE KEY保存业务唯一性。这样既挡住了重复学号，又让主键永远不受业务规则变化的影响。你可能会觉得多一个主键多占空间，但InnoDB索引本身就是B+树，主键占用的空间换来的是全链路的稳定，这笔账划算。
2.3 时间字段的隐藏规矩
created_at和updated_at经常被初学者忽略，我反而建议这两列在每张业务表里都保留。几乎所有后台页面都需要"最近创建"排序，出了问题审计时要能回溯记录何时写入，没有创建时间的表就是一笔糊涂账。
updated_at这里写了ON UPDATE CURRENT_TIMESTAMP，意思是每次行数据被UPDATE时数据库自动刷新这个字段。别小看这个细节，它让应用层少写代码，也让"最后修改时间"不会因为某个开发忘了赋值而变成NULL。需要注意的是，这个语法是MySQL的实现，其他数据库的写法不完全一样。如果未来的SchoolDB要跑在PostgreSQL上，就要换成triggers或应用层维护，提前想清楚技术栈再决定怎么写。
3. 教师表与课程表：一对多关系怎么落
3.1 教师表DDL
教师表的结构和学生表高度相似，因为它同样适用"代理主键+业务唯一键"的模式。教师表叫teacher，具体DDL如下：
CREATE TABLE teacher ( id BIGINT UNSIGNED AUTO_INCREMENT COMMENT '主键', teacher_no VARCHAR(20) NOT NULL COMMENT '工号', name VARCHAR(64) NOT NULL COMMENT '姓名', title VARCHAR(32) DEFAULT NULL COMMENT '职称：助教/讲师/副教授/教授', department VARCHAR(64) DEFAULT NULL COMMENT '所属院系名称（冗余字段）', phone VARCHAR(20) DEFAULT NULL COMMENT '联系电话', email VARCHAR(128) DEFAULT NULL COMMENT '邮箱', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), UNIQUE KEY uk_teacher_no (teacher_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='教师表';职称title和院系department我没有单独建表，第一版先用VARCHAR顶着。职称的评价维度太固定，翻来覆去就那几种，字符串长度给到32完全够。院系部门虽然听起来像一个独立实体，但初期业务里只是用来筛选和展示，没有独立的统计需求，拆一张department表反而让数据模型多一跳。
这里和student表有个明显的区别：teacher表没有给title和department建索引。原因是索引要跟着查询走，初期并不会频繁按职称或院系做范围过滤，等真有这个需求再补KEY也不迟。索引不是装饰品，每多一个索引就多一份写入成本。
3.2 课程表DDL：谁该持有teacher_id
课程的归属关系是这张表的重点。一门课程通常有一位负责教师，所以course表里保存teacher_id，一个teacher可以开出多门课，这就是典型的一对多关系。DDL如下：
CREATE TABLE course ( id BIGINT UNSIGNED AUTO_INCREMENT COMMENT '主键', course_code VARCHAR(20) NOT NULL COMMENT '课程编号', course_name VARCHAR(128) NOT NULL COMMENT '课程名称', credit DECIMAL(3,1) NOT NULL DEFAULT 0 COMMENT '学分', hours SMALLINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '总学时', teacher_id BIGINT UNSIGNED DEFAULT NULL COMMENT '负责教师ID', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), UNIQUE KEY uk_course_code (course_code), KEY idx_teacher_id (teacher_id), CONSTRAINT fk_course_teacher FOREIGN KEY (teacher_id) REFERENCES teacher(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='课程表';credit用DECIMAL(3,1)而不是FLOAT，是因为学分存在0.5这种半分制。FLOAT在数据库中存储的是近似值，当初看起来是0.5，算总数时可能出现0.499999这样的误差。DECIMAL是精确数字类型，做学分求和才靠得住。hours用SMALLINT就够，普通课程总学时几乎不会超过32767小时。
课程编号course_code设了UNIQUE KEY，因为它是课程维度的业务标识。课程名字course_name可能重复，现实中确实存在同名但不同编号的课程，所以唯一性要绑在course_code上，不要绑在course_name上。
也许有人会问：为什么course表里不直接存教师姓名，而是存teacher_id？原因同样是稳定性。教师可能改名、可能调走，如果课程表里冗余一份姓名，改名的代价就是批量UPDATE这张表。存teacher_id之后，展示姓名时走JOIN即可，姓名变化只改teacher表一行。
3.3 外键到底建不建
这是DDL设计里最容易被争论的点。我在course表里写了物理外键fk_course_teacher，但在真实的分布式或高并发项目里，很多团队会刻意去掉物理外键、只保留普通索引，由应用层保证引用完整性。
两种方案各有利弊。物理外键的最大价值是数据库层面兜底：如果INSERT时teacher_id指向的教师不存在，直接报错；如果尝试删除还在开课的教师，ON DELETE行为会自动拦截或级联。缺点是建索引、做完整性检查都要消耗性能，而且在大批量导入、分库分表场景中，外键会变成迁移负担。
对于SchoolDB这种数据量不大、正确性优先级很高的教学型或内部型系统，我更建议保留物理外键。但要注意一个前提：外键两侧的字段类型和排序规则必须完全一致。我见过最典型的报错就是父表id用BIGINT，子表teacher_id用INT，建外键时直接报"列类型不兼容"。所以设计之初就要把类型约定统一，不能今天建一张表一个样。
4. 选课成绩表：联合约束是这张表的灵魂
4.1 完整DDL
选课成绩表是整个4张表里关联关系最密集的一张，它一头连着学生，一头连着课程，同时还要承载成绩语义。DDL如下：
CREATE TABLE course_selection ( id BIGINT UNSIGNED AUTO_INCREMENT COMMENT '主键', student_id BIGINT UNSIGNED NOT NULL COMMENT '学生ID', course_id BIGINT UNSIGNED NOT NULL COMMENT '课程ID', semester VARCHAR(16) NOT NULL COMMENT '学期，格式如2024-2025-1', score DECIMAL(4,1) DEFAULT NULL COMMENT '成绩，NULL表示未出分', status TINYINT UNSIGNED NOT NULL DEFAULT 1 COMMENT '状态：1-在读 2-通过 3-未通过 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 (id), UNIQUE KEY uk_student_course_semester (student_id, course_id, semester), KEY idx_course_id (course_id), KEY idx_semester (semester), CONSTRAINT fk_selection_student FOREIGN KEY (student_id) REFERENCES student(id), CONSTRAINT fk_selection_course FOREIGN KEY (course_id) REFERENCES course(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='选课成绩表';相比前三张表，这张表多了两个外键和一个联合唯一键，它们就是这张表的灵魂。
4.2 联合唯一键为什么要存在
uk_student_course_semester (student_id, course_id, semester) 解决了选课系统最核心的防重问题：同一个学生在同一个学期不能重复选择同一门课。你可能觉得这个约束在应用层判断就够了，但在高并发场景下，两个完全相同的选课请求同时到达，应用层先查后插的判断会被中间那一瞬间的并发窗口穿透，等到两个INSERT都提交，唯一的兜底就是数据库约束。
联合唯一键字段的顺序有讲究。我故意把student_id放第一位，因为最常出现的查询是"某个学生这个学期选了哪些课"。B+树联合索引最匹配最左前缀，这个顺序能让该查询直接命中uk_student_course_semester索引。如果你把semester放第一位，查学生选课列表时反而用不上联合索引，还得绕到二级索引回表。
这里可以对照一个反例：如果有业务需求是"某一门课在某个学期有多少人选"，查询条件是course_id和semester，少了字段顺序匹配，联合索引就帮不上忙，所以要单独建一个idx_course_id。这就是为什么不能只靠联合索引吃饭，业务有多样化查询，索引就得跟着多样化。
4.3 成绩字段的数据类型与NULL语义
score用DECIMAL(4,1)，这个精度是算过的。满分100分的百分制成绩，最多需要4位有效数字（三位整数加一位小数），DECIMAL(4,1)表示总位数4位、小数位1位，最大能存999.9，覆盖百分制绰绰有余。不要用DECIMAL(5,2)，多给一位整数和一位小数纯粹浪费空间，做排序统计时也没有收益。
score允许NULL而不是默认0，这一点非常关键。NULL代表"还没有成绩"，0代表"成绩是0"。如果都拿0表示，期末统计时会把没参加考试的人误算成0分。判断一个学生是否出分，用score IS NULL即可，语义干净。
status字段把这张表扩展成了选课和成绩两条业务，值为1表示在读，2表示通过，3表示未通过，0表示退课。score和status可以组合使用：score有值但status标记为在读，说明成绩已录但还没审核；status变成2或3时，成绩才正式生效。第一次设计时可以不考虑这么细，但预留状态位绝对不吃亏。
MySQL 8.0.16之后CHECK约束开始真正生效，所以也能给score加上CHECK (score IS NULL OR (score >= 0 AND score <= 100))。不过要注意，旧版本MySQL对CHECK会直接忽略，如果团队还在用5.7，这个约束则形同虚设。
4.4 为什么保留自增主键
选课成绩表已经有了联合唯一键，为什么不直接把(student_id, course_id, semester)写成复合主键？这是我在设计时认真考虑过的问题。
复合主键在语义上确实更"正"，但代价也很明显：InnoDB中主键就是聚簇索引，复合主键会让聚簇索引体积变大，每个二级索引里都要冗余保存完整主键值。而且这张表未来可能被别的业务引用，比如补考记录、成绩复议记录，其他表存一个单列主键id远比存一堆复合字段方便。
所以我最终选择了"单列自增主键+联合唯一键"的组合。主键负责聚簇存储和对外引用，联合唯一键负责业务防重，各司其职。对一张记录量可能在百万级别的表来说，这个设计在空间和灵活性上都很均衡。
5. 落地前必须确认的工程细节
5.1 引擎、字符集和排序规则
这4张表统一默认ENGINE=InnoDB。InnoDB支持事务和行级锁，MyISAM不支持外键也没有事务，只适合纯只读的归档表。SchoolDB里有选课、改成绩这类写操作，MyISAM一旦中途崩溃表容易损坏，所以没有任何理由在这里选MyISAM。
字符集统一用utf8mb4，这一点在中文系统里尤其重要。MySQL的utf8实际上最多只存3个字节，遇到emoji和部分生僻汉字就会变成问号；utf8mb4才是真正的完整Unicode。学生名字这一列哪天出现生僻字，你就知道utf8mb4有多重要了。另外建议再加COLLATE=utf8mb4_unicode_ci，它比general_ci的排序更符合通用语言习惯，代价是排序性能略低，对学校系统的数据量完全没影响。
要注意的一点是：字符集和排序规则在库、表、列三个层级都可以单独指定。建库时指定一次，建表时不写，表会自动继承库的配置。但如果用了可视化工具建表，工具常常会塞进一堆你没意识到的默认值，建议直接检查最终SQL。
5.2 命名规范统一
这4张表里，表名我全部用单数：student、teacher、course、course_selection。为的是阅读SQL时更接近自然语义。我知道有很多团队喜欢复数，这本身不是问题，真正的问题是"不统一"。一个数据库里一半单数一半复数，后面的维护者会非常痛苦。
字段名统一snake_case，小写加下划线。不要出现teacherID这种驼峰或大小写混拼的写法，容易在不同操作系统和框架间踩大小写敏感的坑。唯一键统一命名为uk_表名单字段，外键统一命名为fk_表名_字段，索引统一用idx_。这套命名规范可能不起眼，但它让所有人在不看注释的情况下都能推断出一个索引的用途。
还有一点：尽量避免用name这样过于通用的词单独做字段名。学生表里写name，教师表里写name，等你写JOIN时就会得到一堆需要别名的name。在业务表里给字段带上用途前缀更清晰，比如course_name、teacher_name。
5.3 三类索引的实际场景
每张表上的索引不是摆设。拿这4张表举例，常见的查询路径是这样走的：
- 登录或校验学生：SELECT * FROM student WHERE student_no = 'xxx'，命中uk_student_no唯一索引，最多返回一行。
- 查看某学生本学期选课：SELECT * FROM course_selection WHERE student_id = 1 AND semester = '2024-2025-1'，命中uk_student_course_semester的最左前缀。
- 查某门课程的选课名单：SELECT * FROM course_selection WHERE course_id = 10，命中idx_course_id。
- 查某个教师的课程列表：SELECT * FROM course WHERE teacher_id = 5，命中idx_teacher_id。
索引不是越多越好。每张表引入一个新索引，INSERT和UPDATE都会多维护一棵B+树，所以在设计阶段先想清楚核心查询长什么样，再给索引列表做减法才是正确的顺序。
5.4 从4张表扩展出完整SchoolDB的路径
这套4张表的骨架后续扩展起来非常清晰。当班级概念变强时，可以新建class表，在student表里加class_id外键；当院系统计需求变多时，把teacher.department和student.major分别抽成department表、major表；当开课需要多教师协作时，新建teaching_team表，把course和teacher的关系从一对多变成多对多。
扩展的原则只有一个：先让业务闭环在现有结构上跑通，再在真实需求的驱动下补充关系，不要为了"看起来完整"提前拆表。SchoolDB这个项目真正的价值不在于表有多少张，而在于你理解了一组表结构是怎么一步一步从业务需求里生长出来的。
最后聊几句个人体会。我在整理这4张表的时候，最大的感受是"克制"二字。开发阶段常常会冒出很多需求——要不要存宿舍号、要不要记录家长联系方式、要不要给课程加教室字段——这些都很合理，但一股脑塞进第一版就是灾难。做数据库设计的顺序应该是先把最核心的实体和关系稳住，再让需求和表结构一起迭代。
如果你把这4张DDL拿到自己项目里去用，我建议你先花10分钟做一件事：把每个表里每个字段对应的查询场景写出来，查得到就留下，查不到就想想是否需要，想不清楚就删掉。这样一轮做完，你手里的表结构就会比绝大多数随手建的版本干净得多。
