weixin_292004851. 内容整体设计与思路拆解
1.1 数据模型到底解决什么问题
先别急着把它当成一个枯燥的数据库理论问题。我做了这么多年数据相关工作，最大的感受是：数据模型是所有业务系统中最先被轻视、最后被骂惨的东西。你想想看，一个教务系统，学生、课程、成绩、教师、班级，这些数据每天都在产生，而且彼此关联。如果没有一套清晰的数据模型，后面的查询、统计、报表、权限控制全都得推倒重来。就好比盖房子不打地基，先砌墙，结果墙越砌越歪，最后只能拆了重来。
"03.02.01.02 Implement a Data Model: Basics"这个标题看起来像是某个课程体系里的一个模块，但本质上它在讲一件非常核心的事：如何把一个业务场景里的信息，转化成计算机能存储、能管理、能查询的结构化形式。数据模型就是这个转化过程的产物和载体。它的核心价值在于——让数据在存储之前就有了明确的意义和组织方式，而不是像一堆散落的文件堆在硬盘里。
我们以教务系统为例子来拆解。教务系统的数据模型，本质上要回答这几个问题：这个系统里有哪些"人"和"物"？比如学生、教师、课程、教室。它们各自有哪些属性？比如学生有学号、姓名、专业；课程有课程代码、学分、开课院系。它们之间是什么关系？一个学生可以选多门课，一门课也可以被多个学生选——这是典型的多对多关系；一个学院下有很多个专业，一个专业下有很多个班——这是一对多关系。把这些信息梳理清楚，形成一个稳定的结构，就是数据模型设计的核心工作。
我一直认为，数据模型设计不是一个纯技术活，它更接近业务分析和逻辑思维的训练。你不需要一开始就写SQL、建表，而是在脑子里把业务逻辑想清楚。这也是我在带新人时反复强调的一句话：数据模型设计得好不好，不取决于你会不会写代码，而取决于你有没有把业务想透。
1.2 为什么用教务系统作为切入案例
教务系统这个场景是我特别推荐用来讲数据建模基础的，因为它天然覆盖了数据建模中最关键的所有关系类型和设计难点，同时不需要任何行业背景知识。
来看一下教务系统里的典型角色和实体：学生、教师、课程、班级、学院、专业、选课记录、成绩单。这里面包含了一对一（一个学生对应一个学籍档案）、一对多（一个学院对应多个专业）、多对多（学生和课程之间通过选课产生联系）三种基本关系形态。另外，它还有层次关系——学院下有专业，专业下有班级，班级下有学生。这种层次结构在组织和权限系统中非常常见。
更关键的是，教务系统里的数据模型涉及到一个非常有代表性的设计难点：业务实体的属性变化。举个最简单的例子，一个学生的"专业"是不是一个固定不变的属性？不一定。有的学校允许学生转专业，那么专业字段就不能焊死在这一个学生记录上，而要考虑它是否应该独立成一个实体。这种"属性升级为实体"的过程，正是数据建模中最见功力、也最容易踩坑的地方。你用教研系统的例子来讲这个点，比用"用户表"这种空泛的例子要直观得多。
所以，这篇博文接下来会围绕一个可以完整跑通的教务系统数据模型，从ER图、关系设计、范式检查、建表SQL，一直讲到常见坑和排查思路。整个过程我会用我实际踩过坑的经验来讲，保证你学完就能用它来应对真实项目中 "给我设计一套数据模型" 的需求。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心细节解析与实操要点
2.1 实体、属性、关系这三件事怎么落地
很多初学者在拿到一个需求时，第一反应是"赶紧建表"。这个习惯很不好。正确做法是先做实体识别，也就是把业务中的"名词"找出来。学生、教师、课程、班级、学院、选课记录、成绩单，这些都是名词，它们大概率会成为数据模型里的实体。但要注意，不是所有名词都要建成表。比如"姓名"是学生的属性，不是独立实体；"学分"是课程的属性，也不是独立实体。区分"实体"和"属性"的关键是：这个信息是否需要被独立管理和查询？如果一个东西只是服务于另一个东西的描述，那它就是属性；如果它自己有生命周期、有独立的业务规则，那它就应该升级为实体。
属性识别这个环节，我建议用"一问一答"的方式来验证。比如：学生有哪些属性？学号、姓名、性别、出生日期、入学年份、所属班级、联系方式。这些信息在业务上有没有独立的查询需求？比如"查所有某年入学的学生"——这是基于属性的查询，不是基于实体的查询，所以它们作为学生表的字段就够了。但反过来，"专业"这个信息——一个专业可以被多个学生共享、一个学院有多个专业、专业有独立的培养方案——它明显是一个有独立生命周期和规则的东西，所以专业应该单独建表，学生表只存专业ID。
关系识别比实体识别更容易出错。我的经验是，先确定两个实体之间的"数量关系"，再倒推如何设计外键或中间表。一对多关系最简单——把"一"的那一方的主键放到"多"的那一方做外键。多对多关系则需要第三张中间表，比如"选课记录"就是学生表和课程表之间的中间表。一对一关系相对少见，但在教务系统里也不是没有——比如一个学生对应一个学籍档案，这种情况可以考虑合并成一张表，也可以拆成两张表用相同主键关联，具体取决于业务上是否经常单独访问学籍信息。
2.2 主键设计与外键落位的三个典型坑
主键设计看起来很简单，但实际坑很多。我做技术支持时，最常见的一个请求就是"来帮我看下为什么这个查询这么慢"，查来查去，多半是主键设计或索引设计出了问题。
第一个坑是：轻易使用业务字段做主键。比如用"课程代码"这种业务上唯一的字段作为课程表主键。看着没问题，但万一哪天课程代码的编码规则调整了呢？你所有引用这张表的外键都得跟着变。我在实际项目中真的遇到过这种凌晨三点的生产事故。所以我的原则是：除非业务字段绝对不可能变化（比如身份证号级别的稳定性），否则一律用自增ID或UUID作为主键，用唯一索引约束业务字段的唯一性就够了。
第二个坑是：多对多关系的中间表没有独立主键。有些同学建选课表的时候不建ID，直接用(student_id, course_id)作为联合主键。这在纯技术上没有问题，但会让后续开发和扩展非常痛苦——当"选课"这个行为自身拥有越来越多的属性（选课时间、选课状态、成绩、退课时间）时，中间表实际上已经升级为一个业务实体了，它应该有自己的独立主键。否则后面做按选课记录维度的统计、日志、审计时，会发现连一个稳定的记录标识符都没有。
第三个坑是：外键到底加不加。这是个老生常谈但又永远有人在争论的问题。我的观点是：对于数据一致性要求高的业务，必须加数据库层面的外键约束，比如成绩表里的学生ID必须能对应到学生表里真实存在的学生；如果系统规模大到写入性能要求的极致，那么可以谨慎考虑不用物理外键，但必须在应用层实现等效的一致性校验。千万不要在连业务都没想清楚的情况下就取消外键，那等于把"数据一致性"这个责任扔给了不知道哪一层去处理。
2.3 从ER图到表的映射规则
画ER图时只需要考虑实体和关系，但落地到表结构时有一件非常关键的事必须先确定——关系落位的方向。
一对多关系设计时要考虑"外键往哪边放"。比如学院和专业，一个学院下有多个专业，那么外键应该放在专业表，即专业表里带college_id。这个方向是跟着"多"的一方走的。实际操作中，这个关系的语义要反复确认——是一个专业只属于一个学院，还是允许跨学院联合培养？如果是后者，这一对多就变成多对多关系，需要引入关联表了。很多人在这一步想当然，导致后面业务逻辑各种对不上。
多对多关系的落地则统一用中间表。学生和课程是典型的多对多：一个学生选多门课，一门课有多个学生选。那我们就建一张选课表，把student_id和course_id放进去。这里有个隐藏问题：中间表里的"分数"字段，到底属于谁？明确说来，它不是学生表的属性，也不是课程表的属性，而是"这个学生选这门课"这个行为产生的属性，所以它必须放在选课表里。理解这一点，你就掌握了"关系本身也可以有属性"这一建模精髓。
一对一关系在教务系统中较常见的是"学生"和"学籍档案"。如果学籍档案里带有大量敏感信息且经常需要严格控制访问权限，建议拆成两张表，这样在做权限控制时，只有需要访问学籍档案的模块才会去查那张表，避免每次查询学生信息时都要带着一大坨不相关的数据。
3. 实操过程与核心环节实现
3.1 需求梳理——先列业务规则再动手
我见过太多人一上来就写建表语句，写到一半发现漏了个需求又回来改表结构，然后改表结构又牵连一堆代码。所以在真正写SQL之前，我建议先做一个业务规则清单，把系统里需要满足的条件明确写出来。
以教务系统为例，核心业务规则如下：
- 每个学生属于且仅属于一个班级，每个班级属于一个专业，每个专业属于一个学院。
- 一个学生可以选择多门课程，每门课程也可以被多个学生选择；选课后产生成绩，成绩范围0-100或等级制。
- 每个教师属于一个学院，可以教授多门课程；一门课程在某个学期只能由一个教师负责，但同一门课在不同学期可以由不同教师负责。
- 课程有课程代码和学分属性，学分可能影响毕业审核规则。
这些规则是数据模型设计的"需求输入"，表结构就是用来满足这些规则的"输出结果"。做这一步时，我的建议是一定要和业务方逐条确认，特别是"每个""至少""最多""必须"这些词，它们会直接决定关系的基数和约束条件。比如"每个学生属于且仅属于一个班级"就说明学生表和班级表是多对一关系，学生表里必须有一个不能为空的class_id字段，并且要加外键约束。有了这种明确的规则，后面建表时心里就非常有底了。
3.2 建表SQL——从概念模型到物理模型的完整落地
下面我给出核心表的建表SQL。考虑到不同学校的数据库环境不太一样，我这里用MySQL 8.0语法来示范，但设计思路是完全通用的。
先建学院表、专业表、班级表这三个基础组织架构表：
sql复制CREATE TABLE college (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
college_code VARCHAR(20) NOT NULL UNIQUE COMMENT '学院编码',
college_name VARCHAR(100) NOT NULL COMMENT '学院名称',
dean VARCHAR(50) COMMENT '院长姓名',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE major (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
major_code VARCHAR(20) NOT NULL UNIQUE COMMENT '专业编码',
major_name VARCHAR(100) NOT NULL COMMENT '专业名称',
college_id BIGINT UNSIGNED NOT NULL COMMENT '所属学院ID',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
CONSTRAINT fk_major_college FOREIGN KEY (college_id) REFERENCES college(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE class (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
class_code VARCHAR(20) NOT NULL UNIQUE COMMENT '班级编码',
class_name VARCHAR(100) NOT NULL COMMENT '班级名称',
major_id BIGINT UNSIGNED NOT NULL COMMENT '所属专业ID',
grade_year INT NOT NULL COMMENT '入学年份，如2024',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
CONSTRAINT fk_class_major FOREIGN KEY (major_id) REFERENCES major(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
这里有一个很关键的设计说明：班级表里存了专业ID，而不是把专业信息冗余在班级表里。这样当专业信息变化时，只需要改专业表，班级表不需要动。同理，学院表的ID被专业表引用，专业表的ID被班级表引用，就形成了一个链式层级。这属于典型的"通过引用而不是冗余来组织数据"的思路，是数据建模最基础的思维方式。
然后建最核心的两张业务实体表：学生表和教师表。
sql复制CREATE TABLE student (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
student_no VARCHAR(20) NOT NULL UNIQUE COMMENT '学号',
name VARCHAR(50) NOT NULL COMMENT '姓名',
gender TINYINT NOT NULL DEFAULT 0 COMMENT '性别：0未知，1男，2女',
birth_date DATE COMMENT '出生日期',
enroll_year INT NOT NULL COMMENT '入学年份',
class_id BIGINT UNSIGNED NOT NULL COMMENT '所属班级ID',
phone VARCHAR(20) COMMENT '联系电话',
email VARCHAR(100) COMMENT '邮箱',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
CONSTRAINT fk_student_class FOREIGN KEY (class_id) REFERENCES class(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE teacher (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
teacher_no VARCHAR(20) NOT NULL UNIQUE COMMENT '教师工号',
name VARCHAR(50) NOT NULL COMMENT '姓名',
gender TINYINT NOT NULL DEFAULT 0 COMMENT '性别：0未知，1男，2女',
title VARCHAR(50) COMMENT '职称：助教/讲师/副教授/教授',
college_id BIGINT UNSIGNED NOT NULL COMMENT '所属学院ID',
phone VARCHAR(20) COMMENT '联系电话',
email VARCHAR(100) COMMENT '邮箱',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
CONSTRAINT fk_teacher_college FOREIGN KEY (college_id) REFERENCES college(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
学生表里的class_id指向班级表，这样学生和班级的关系就落位了。教师表里college_id指向学院表。
接着建课程表和选课表——这是整个教务系统数据模型里最需要动脑子的两张表：
sql复制CREATE TABLE course (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
course_code VARCHAR(20) NOT NULL UNIQUE COMMENT '课程代码',
course_name VARCHAR(100) NOT NULL COMMENT '课程名称',
credit DECIMAL(3,1) NOT NULL DEFAULT 0 COMMENT '学分，如2.5',
course_hours INT NOT NULL DEFAULT 0 COMMENT '总学时',
teacher_id BIGINT UNSIGNED NOT NULL COMMENT '授课教师ID',
college_id BIGINT UNSIGNED NOT NULL COMMENT '开课学院ID',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
CONSTRAINT fk_course_teacher FOREIGN KEY (teacher_id) REFERENCES teacher(id),
CONSTRAINT fk_course_college FOREIGN KEY (college_id) REFERENCES college(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE course_selection (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
student_id BIGINT UNSIGNED NOT NULL COMMENT '学生ID',
course_id BIGINT UNSIGNED NOT NULL COMMENT '课程ID',
term VARCHAR(20) NOT NULL COMMENT '学期，如2024-2025-1',
score DECIMAL(5,2) COMMENT '课程成绩，百分制',
status TINYINT NOT NULL DEFAULT 0 COMMENT '0-已选，1-已退课，2-已结课',
selected_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '选课时间',
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
CONSTRAINT fk_selection_student FOREIGN KEY (student_id) REFERENCES student(id),
CONSTRAINT fk_selection_course FOREIGN KEY (course_id) REFERENCES course(id),
CONSTRAINT uk_student_course_term UNIQUE KEY (student_id, course_id, term)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
注意课程表里直接放了teacher_id，这相当于目前课程和教师是"多对一"关系，也就是一门课当前只对应一个负责教师。但在真实教务系统里，一个教师可以教多门课，那就需要连接表来实现"多对多"——即一门课可以有多个教师参与，一个教师可以参与多门课程。这部分可以根据业务的精确语义去调整。我这里使用的是"课程-教师一对一"的最简设计，方便讲解。
选课表是整张ER图中最重要的桥梁。它把student_id和course_id连在一起，还加上了联合唯一键(student_id, course_id, term)，防止同一个学生在同一个学期重复选择同一门课程。这个唯一约束很重要——如果没有这个约束，应用层逻辑一漏，就会出现重复选课记录，后面统计成绩、算学分全乱掉。
3.3 用几条数据验证模型是否合理
表建好了，不代表设计就没问题。我习惯在实际联调之前，先插入几条模拟数据，把核心的业务查询场景跑一遍。这一步能快速暴露模型设计上的缺漏。
先插入基础数据：
sql复制INSERT INTO college (college_code, college_name, dean) VALUES
('CS', '计算机学院', '张老师');
INSERT INTO major (major_code, major_name, college_id) VALUES
('SE', '软件工程', 1);
INSERT INTO class (class_code, class_name, major_id, grade_year) VALUES
('SE202401', '软件工程2024级1班', 1, 2024);
INSERT INTO student (student_no, name, gender, birth_date, enroll_year, class_id) VALUES
('2024001', '张三', 1, '2006-03-15', 2024, 1),
('2024002', '李四', 0, '2006-07-22', 2024, 1);
INSERT INTO teacher (teacher_no, name, title, college_id) VALUES
('T001', '王老师', '副教授', 1);
INSERT INTO course (course_code, course_name, credit, course_hours, teacher_id, college_id) VALUES
('CS101', '数据结构', 4.0, 64, 1, 1);
INSERT INTO course_selection (student_id, course_id, term, score, status) VALUES
(1, 1, '2024-2025-1', 88.5, 2),
(2, 1, '2024-2025-1', 75.0, 2);
然后跑几个典型的查询场景。比如查询某个学生的选课列表，包括课程名和学分：
sql复制SELECT s.name, c.course_name, c.credit, cs.score
FROM student s
JOIN course_selection cs ON s.id = cs.student_id
JOIN course c ON cs.course_id = c.id
WHERE s.student_no = '2024001';
再比如统计某个专业的平均成绩：
sql复制SELECT m.major_name, ROUND(AVG(cs.score), 2) AS avg_score
FROM major m
JOIN class cl ON m.id = cl.major_id
JOIN student s ON cl.id = s.class_id
JOIN course_selection cs ON s.id = cs.student_id
WHERE m.id = 1
GROUP BY m.id, m.major_name;
如果这些查询能顺利跑通且结果符合预期，说明模型基本是可靠的。我在这个环节中还有一个小习惯——顺手写几个"破坏性测试"，比如插入一条不存在的student_id的选课记录，看看外键约束有没有拦截住。如果拦截了，说明数据完整性有保障；如果没拦截，就说明约束设计漏掉了，需要补上。
4. 常见问题与排查技巧实录
4.1 主键选择困难，自增还是UUID
主键选择是数据建模里讨论最热烈的细节之一。自增主键占空间小、写入性能高、索引效率好，但由于ID会被外界获知，容易造成信息泄露（比如有人可以通过ID差值判断系统注册量），并且在分库分表场景下容易冲突。UUID主键解决了分布式的全局唯一问题，但它占用的存储空间更大（36位字符串对B+树索引不够友好），且无序的UUID会导致索引页频繁分裂，写入性能下降。
我的建议是分场景看：小规模单体应用，优先自增主键，配合唯一索引保证业务字段的唯一性；分布式系统或需要在多节点生成唯一ID的场景，可以采用雪花算法等有序ID方案，兼顾性能和数据安全。总之，"业务字段永远不要做主键"这条底线不要破。
这个坑在教务系统里也很常见。有些开发图省事，直接用student_no（学号）作为student表的主键，因为学号看起来全局唯一。但学号是有编码规则的，将来学籍管理制度一调整，学号规则变了，你所有的关联表外键都要跟着改。用自增id做主键，将student_no设成unique key，该唯一还是唯一，但未来扩展空间就大得多了。
4.2 外键约束到底加不加
这是我在社区里被问到最多的问题之一。支持加的人认为数据库保证一致性最可靠，禁止加的人认为外键会影响写入性能和扩展性。我个人的观点是：在业务初期，在数据一致性价值大于性能瓶颈的场景，一定要加外键。它就像一层保险丝，即使应用层代码有bug，数据库也不会让它把脏数据写进去。
等系统规模大到数据库写入已经是明显瓶颈时，再考虑去掉外键约束，但前提是必须有一套完善的应用层校验机制，甚至在必要时引入事务消息、对账任务这样的补偿机制来保证最终一致性。对于刚学习数据建模的读者，我的建议非常简单粗暴：先老老实实把外键加上，别一上来就用谷歌级的架构思维否定数据库的基本能力。
在实际排查问题时，我发现还有个比"加不加外键"更隐蔽的坑——忘记给外键字段加索引。如果外键约束加了，MySQL会自动为外键列创建索引；但如果你没有加物理外键而是用逻辑外键（即只有相同意义的字段但没有约束），那么一定要手动给这个字段建索引。否则，所有通过外键关联的查询都会变成全表扫描，数据量一大，慢查询会接踵而至。
4.3 多对多关系忘了拆中间表
这是初学建模时最容易犯的错误。比如学生和课程，很多初学者看到业务说"一个学生选多门课"，就在student表里加一个course_ids字段，用逗号分隔多个课程ID。这在演示demo里看着能用，但真到了实际生产环境，要么写复杂到无法维护的SQL去解析字符串，要么无法使用JOIN做关联查询。更重要的是，这种设计完全无法承载"选课"这个行为自身的属性和生命周期。
正确做法永远是拆中间表。以选课表为例，它不仅保存student_id和course_id，还能记录学期、成绩、选课状态、选课时间，甚至将来还能扩展出退课操作记录、成绩修改审计日志等。如果你贪图省事没有拆中间表，未来每加一个新需求都要改表结构，改一次痛一次。
4.4 第二、第三范式的现实判断标准
教科书上对范式的定义比较抽象，我讲个更实用的判断方法。第二范式说的是，非主键字段必须完全依赖于主键，不能依赖于主键的一部分。这条在联合主键场景下非常重要。比如一张选课表，主键是(student_id, course_id)，如果你把课程名称也放进去，那"课程名称"其实只依赖course_id，不依赖student_id——这就违反了第二范式。一旦违反，课程名称改了要更新所有选该课程的学生记录。所以我的判断标准很简单：如果一个字段的"值"能被多个记录共享，并且它的变化需要批量更新，那它就应该被抽走放到另一个实体表里去。
第三范式说的是，非主键字段之间不能存在传递依赖。比如学生表里有class_id和class_name，但class_name依赖于class_id而不是student_id，这就是传递依赖。如果你需要班级名称信息，应该通过JOIN从班级表里取。冗余某些字段当然是常见优化手段，但应该是在你明确知道"这里需要冗余、并且接受数据不一致风险"的情况下才做，而不是因为建表时没想清楚。
我给大家一个实用建议：先把表设计成完全满足第三范式的"标准形态"，等业务明确出现性能瓶颈时，再通过冗余字段或预计算表做针对性优化。不要一来就"优化"，因为对基础模型来说，结构的干净和可维护性远比省一两个JOIN更重要。
4.5 命名规范与后续扩展建议
最后说一个最容易被忽略，但后期成本最高的基础问题——命名规范。我在维护老系统时就深受其苦：有的表用单数命名，有的用复数；字段一会用created_at，一会用gmt_create；主键一会儿叫id，一会儿叫student_id。到后面维护的时候，每查一次表都要先理解这套混乱的命名逻辑，思维负担非常大。
我的建议是：表名统一用业务实体的单数形式，如student、course、teacher；主键统一叫id；外键明确用"业务_实体_id"的形式，如student_id、course_id；时间字段统一为created_at、updated_at；布尔字段用is_xxx；状态字段用status并且注释里写明每个数值的含义。这些规范执行起来成本极低，但对于团队协作和后续维护收益巨大。
关于教务系统数据模型的后续扩展方向，我简单提几个思路供参考：一是增加学期表和排课表，把"教师、课程、上课时间、教室"统一挂在一个学期维度下；二是增加成绩审核流程相关的字段，比如成绩录入状态、审核人、录入时间；三是考虑将班级升级为更灵活的"行政班/教学班"两种概念；四是引入数据字典表来管理性别、职称、课程类型等枚举值。这些扩展都是在你打好基础数据模型后，自然生长出来的需求。
我个人在实际操作中还发现，很多看似复杂的数据模型问题，归根结底都是因为在最初建模时没有把实体关系和业务规则想清楚。数据模型的"基础"这两个字里，藏着的恰恰是整个系统最核心、最不容易改动的部分。你花一周时间把模型设计清楚，未来就能省下无数周在混乱的数据结构中补漏洞的时间。这个账，怎么算都划算。