课程表管理系统需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 没索引，全表扫描是必然的。
以下约束不是可选项：
