课程计划与课次：从安排规则到一次实际发生
用课程日历说明计划与课次的区别，讨论改期、取消和历史记录应如何进入数据模型。
先区分两种记录
做课程日历时，可以先把课程计划和课次分开。计划描述长期安排，例如课程名称、适用日期以及每周的时间规则；课次描述一次具体安排，包含开始时间、结束时间、地点和当前状态。一份每周重复的计划会产生多条课次，两者通过稳定的标识关联。
假设计划要求每周三下午上课，其中一次临时改到周四。这次改期属于单个课次，通常不应改变以后每周的规则。相反，如果从下个月起统一调整时间，就需要记录新规则的生效日期，并明确哪些尚未执行的课次可以随之更新。
让数据库守住基本关系
最小模型可以包含计划表和课次表：计划表保存自身标识与安排规则，课次表保存自身标识、计划标识及实际时间。不要用课程名称充当关联键，名称可能重复或更改。外键可以帮助发现课次引用了不存在计划的错误，但数据库约束需要正确配置才能生效。
SQLite 支持外键、唯一性和检查约束。使用时应为连接明确启用外键检查，并通过测试确认生效。结束时间晚于开始时间等条件可以写成检查约束；同一计划同一时段是否允许多条课次，则取决于业务规则，不能只凭避免重复的直觉加上唯一限制。
为变化保留解释
已结束的课次记录的是当时发生的事实。后续修改计划名称或默认教师时，应先确定历史页面展示当前名称还是当时快照。两种方式各有用途，关键是提前约定。涉及已确认结果的修改，可以保留修改前后值、时间和原因，避免后来的规则悄悄改写旧记录。
取消也值得单独建模。如果直接删除课次，日历虽然干净了，却难以解释为什么少了一次。保留取消状态能支持查询与统计。设计完成后，用正常排课、单次改期、未来规则变更和取消四个例子走一遍，观察每一步会改动哪些记录，比先堆出很多字段更容易发现问题。