我正在构建一个日历网站(ASP.NET MVC)应用程序(认为是Outlook的简单版本)，并且我想开始支持重复发生的日历事件(每月，每年等)
现在我要在其中存储实际日期，但我想弄清楚是否可以继续存储日期(有明显的中断)是否有意义，还是应该存储重复选项并即时生成日期。
这让我开始思考Outlook，Google Mail等如何执行此操作或支持重复日历项目的任何其他服务。
有什么建议吗？
最佳答案
将您的数据分为两部分:“规范”数据(重复规则)和“服务”(生成日期；除重新生成外为只读)。如果规范数据发生变化，请在那时重新生成“服务中”数据。对于无限重复，请保留一定数量的实例并在耗尽时生成更多实例(例如，如果用户查看其2020年的日历)。
如果您具有无限的处理器速度，则只需要规范数据-但实际上，对每个页面 View 上的所有重复规则进行所有日期/时间处理可能会非常耗时...因此您进行交易关闭一些存储(和复杂性)以节省重复的计算。与大量事件所需的计算相比，存储通常非常便宜。如果您只需要存储事件的日期，那确实非常便宜-您可以轻松地使用4字节整数表示日期，然后从中生成一个完整的日期/时间，前提是您的重复周期都是基于日期的。对于基于时间的重复周期(例如“每三个小时”)，您可以完整使用UTC即时消息-8字节代表着您可能需要的很长一段时间内的分辨率。
不过，您需要注意保持有效性-如果今天的定期 session 发生变化，那么过去的 session 不会发生变化...因此，您可能还希望拥有有关实际发生何时复发的规范只读数据。显然，您并不想永远保留过去，因此，您可能希望将“垃圾收集”事件保留几年以上，具体取决于您的存储限制。
您可能还需要能够逐次添加注释和异常(exception)(例如，“由于公共(public)假期而今天没有开会”或“下午4点移动”)。当您更改重复率时，这真的很有趣-如果将“每个星期一”更改为“每个星期二”，是否保留异常(exception)？从“每天”更改为“每周”时，您甚至如何匹配异常(exception)？这些不是直接与存储有关的问题，但是存储决策将影响实现您决定的任何策略的难易程度。