课程表管理系统需student、teacher、course、classroom、schedule五张基础表，其中schedule为枢纽表，关联课程、教师、教室及抽象时间段（周几+节次+周类型），通过student_schedule多对多表支持学生选课，所有外键须加约束与索引以保障查询性能。
课程表管理系统需要哪些核心实体
课程表本质是「时间 + 人 + 课」的三元关系，不能只建一张大表硬塞。必须拆解为 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 的取值范围上提前约定死，否则后期改数据成本极高。
