课程表管理系统需要哪些核心实体
课程表本质是「时间 + 人 + 课」的三元关系，不能只建一张大表硬塞。必须拆解为
student、
teacher、
course、
classroom、
schedule五张基础表，否则后续查谁在哪天哪节上什么课、老师是否冲突、教室是否空闲都会变成 SQL 灾难。
如何设计 schedule 表才能支持真实排课逻辑
schedule是整个系统的关键枢纽，它必须同时关联课程、教师、学生、教室和具体时间段。常见错误是只存
course_id和
teacher_id，漏掉
student_id或用字符串拼学生 ID 列表——这会让「查询某学生本周所有课」变成全表扫描或 JSON 解析，性能极差。
正确做法是用多对多中间表组合：一个
schedule记录对应一门课在某个时段、某个教室、由某位老师讲授；再用
student_schedule关联学生与课表记录（因为一个班有多个学生，但课表安排是按教学班/课程实例来的）。
schedule表含字段：
id、
course_id、
teacher_id、
classroom_id、
week_day（1-7）、
session_start（如 1）、
session_count（连上2节）、
week_type（单周/双周/每周）
student_schedule表只含
student_id和
schedule_id，加联合唯一索引防重复选课 避免在
schedule中存具体日期（如
2024-09-01），而用「周几+节次+周类型」抽象表达，方便学期复用
MySQL 建表时容易忽略的约束和索引
没有外键和索引的课程表数据库，上线后第一个月就会被慢查询拖垮。比如查「周三第3节所有课」，若
schedule.week_day没索引，全表扫描是必然的。
以下约束不是可选项：
所有外键列必须加FOREIGN KEY并配
ON DELETE RESTRICT（删老师前得先清课表）
schedule表至少要有复合索引：
INDEX idx_week_session (week_day, session_start)
student_schedule必须有
UNIQUE INDEX uk_student_sched (student_id, schedule_id)
course表的
code字段（如
MATH101）建议设为
UNIQUE，避免重名课干扰排课
一个最小可行的 schedule 查询示例
用户最常问的是「我这周每天上啥」，对应 SQL 必须能快速定位。下面这个查询假设已知
student_id = 123：
SELECT
c.name AS course_name,
t.name AS teacher_name,
cr.name AS classroom,
s.week_day,
s.session_start,
s.session_count
FROM student_schedule ss
JOIN schedule s ON ss.schedule_id = s.id
JOIN course c ON s.course_id = c.id
JOIN teacher t ON s.teacher_id = t.id
JOIN classroom cr ON s.classroom_id = cr.id
WHERE ss.student_id = 123
AND s.week_type IN ('every', 'odd') -- 根据当前周动态传参
ORDER BY s.week_day, s.session_start;注意：实际应用中
s.week_type的判断（单双周）需由应用层根据学期起始日计算后传入，MySQL 本身不维护日历状态。
真正的难点不在建表，而在于「节次」和「周类型」的业务规则怎么跟教务系统对齐——比如有的学校把上午四节叫 1–4 节，有的拆成 1–2、3–4 两个单元，这些必须在
session_start和
session_count的取值范围上提前约定死，否则后期改数据成本极高。
