掌中生活——设计Q&A

目录

引言

本文整理自 10 月 23 日系统设计与数据库设计课堂答辩的现场提问，逐条回复老师与助教提出的问题，作为本次作业的补充说明。凡回答中引用的图号、表号与约束编号，均与《系统设计说明书 V1.0》《数据库设计说明书 V2.0》保持一致，可直接对照查阅。

评审得分回顾

本次共收回 5 份评分（汪璟玢老师、助教 1-吴、助教 2-卢、助教 3-谭、助教 4-李），总分分别为 91、92、93、92、91，平均总分 91.8（满分 100）。

分维度看，功能模块层次设计（19.0/20）得分率最高；演讲（8.6/10）与接口设计（17.8/20）是得分率相对最低的两个维度。演讲方面将加强时间控制与重点取舍的演练；接口设计虽然文档完整（六个仓储 32 个方法契约），但答辩篇幅限制未充分展开，后续开发阶段会在 Alpha 冲刺的每日站会中结合代码实现持续补齐，并在下次答辩重点展示。

问题一：为什么日期节点和提醒任务之间是一对多？

答：一个日期节点对应多条提醒任务，是本系统提醒模型的核心设计，理由有三层：

第一层：支持多级提前提醒，同一截止日期需要多个推送时间点。

一个日期节点的"提醒"不是一次性的，而是分档的。例如一条证件记录的有效期是 2027 年 1 月 31 日，用户可以设置提前 30 天、提前 7 天、到期当天三次提醒——同一个截止日期，要在三个不同时间点推送通知，自然就派生出了三条提醒任务。在数据模型上，提醒任务不是用户直接录入的对象，而是由日期节点推导出来的结果（触发日 = 到期日 − 提前天数），节点一变、任务即重算。这正是"时间以节点驱动、提醒由数据推导"原则的体现：用户改了到期日，提醒自动跟上，不需要额外的同步逻辑。

第二层：重复周期会让一个节点跨多个到期周期持续派生任务。

日期节点支持"不重复 / 每月 / 每年"三种重复周期（BR-10）。按月重复的扣费日、按年重复的保费日，每个到期周期都会生成一条独立的提醒任务实例。概念设计阶段我们曾把"合并成一个表还是拆成两张表"交给 LLM 重点比较（见本次作业博客的 LLM 示例二）：日期节点保存的是配置（周期、提前天数，设定一次很少改），提醒任务保存的是实例（每一次的执行状态与通知结果，随推送状态流转），两者生命周期完全不同，合并会让配置与运行状态互相牵制，因此最终拆为 date_node 与 reminder_task 两张表，形成 1:N（R-11）。

第三层：修改日期时旧任务不删除，而是"已失效 + 重建"。

如果用户修改了节点的日期，旧的提醒任务不会删掉，而是标记为"已失效"（INVALID），再按新日期重新生成任务——历史记录完整保留；系统扫描（scanDue）与待办查询时直接跳过失效任务，它们不参与排序、不参与推送。这样一来，"改日期"这个动作既不会留下两个互相矛盾的提醒，也不会抹掉曾经提醒过的痕迹，可追溯。

最后，1:N 的派生还配了防重复的库内兜底：生成语句用 INSERT OR IGNORE 配合唯一约束实现幂等——即使调度器因进程重启重复执行生成逻辑，也不会产生重复任务（该行为已由 DB-AC-11 验收用例实测验证）。

结语

感谢老师与助教在答辩现场的提问。日期节点与提醒任务的一对多关系，源于"多级提前提醒 + 重复周期 + 配置与实例分离"三重设计考量：同一个截止日期可以在多个时间点推送通知，同一个节点可以跨多个到期周期持续派生任务，而节点作为配置、任务作为实例的拆分让两者的状态流转互不牵制；修改日期时旧任务以"已失效"保留而非删除，既避免矛盾提醒又保留可追溯的历史。这一提醒模型已经通过数据库验收用例与设计约束检查清单的校验，后续 Alpha 冲刺将按设计逐一实现。