我有类似的问题：How to best handle exception to repeating calendar events。
我的问题是关于数据库设计的。
我有一些活动无限期进行，但有时结束日期是已知的。假设我正在创建一个事件来服用一种药物，所以我知道它什么时候开始，但我不知道什么时候需要停止，这取决于进展情况和医生的建议。
现在有趣的是，虽然我每天都会在特定时间服药，但总有一天它会改变（时间、剂量等）。
所以，我将有一张表来存储药物名称、剂量、开始日期等。
问题： 1. 每天是否有实物记录【具体日期会有所变化】。但是如果我们开始为每个日期存储，可能会有数百万条记录。
或者，我可以对用户更改详细信息的日期有例外。
或者我可以创建 6 个月的记录，当时间接近时，用户可以增加，或者如果活动仍在进行，系统将自动增加。
我想知道 Google 日历如何处理无法定义的重复。
您的建议将不胜感激。
潘卡杰。
【问题讨论】：
标签： sql-server
我会制作一个包含各种可能条件的表格：
table repetition (
event_id int foreign key,
first_date date not null,
last_date date not null,
day_period int null, -- 3 = every 3 days
day_of_month int null, -- 1..31
-- day_of_week int null, -- 0..6, if needed
-- whatever else
)
现在您可以轻松选择今天发生的事件：
select event.*
from repetition
where
-- (day_of_week is null or day_of_week = :current_day_of_week) and
(day_of_month is null or day_of_month = :current_day_of_month) and
(day_period is null or (:current_date - first_date) mod day_period = 0) and
first_date <= :current_date and
last_date >= :current_date
join event on event.id = event_id
(first_date, last_date) 的索引将使查询计划足够高效（索引范围扫描）。
要使范围“无限”，只需将last_date 放在遥远的未来，例如 3000 年。
要处理事件中的“单个”更改，您可以将change_of 列添加到event 表并使其引用回event.id。对于常规事件，它为空。对于更改事件，它存储change_of 指向的事件的覆盖信息。如果您获取当天的两个事件，其中一个有 change_of 指向另一个事件，则您使用来自覆盖事件记录的数据，并忽略 change_of 引用的记录。对于一次性更改，last_date = first_date。
这还允许添加可能有用的重复更改（每隔一天的常规处方和每 14 天更改一次），以及更改时的更改，您可能会通过输入逻辑或触发器来避免这些更改。
【讨论】：
似乎最好存储下一个事件的时间和关于应该多久重复一次的信息。
例子：
Next event: 2011-02-21 08:15
Repeats: Weekly (or any other format you deem appropriate)
“下一个事件”需要在时间到来时递增。
要检查活动是否是今天，请检查 NOW =“下一个活动”的第一部分
【讨论】：