我正在构建一个日历网站 (ASP.NET MVC) 应用程序(考虑简单版本的 outlook)，我想开始支持重复出现的日历事件(每月、每年等)
现在我正在存储实际日期，但我想弄清楚如果有重复，是否继续存储日期(有一些明显的截止日期)是否有意义，或者我应该存储重复选项并生成日期在飞行中。
这让我开始思考 outlook、google mail 等或支持循环日历项目的任何其他服务是如何做到这一点的。
对此有什么建议吗？
最佳答案
将您的数据分为两部分:“规范”数据(重复规则)和“服务”(生成的日期；除重新生成外为只读)。如果规范数据发生变化，则在此时重新生成“服务”数据。对于无限重复，保留一定数量的实例并在用完时生成更多实例(例如，如果用户查看 2030 年的日历)。
如果您有无限的处理器速度，您只需要规范数据 - 但实际上，对每个页面 View 的所有重复规则进行所有日期/时间处理可能是太耗时了……所以你要牺牲一些存储空间(和复杂性)来节省重复计算。与大量事件所需的计算相比，存储通常非常便宜。如果你只需要存储事件的日期，那真的很便宜——你可以很容易地使用一个 4 字节的整数来表示一个日期，然后从中生成一个完整的日期/时间，假设你重复都是基于日期的。对于基于时间的重复(例如“每三个小时”)，您可以使用完整的 UTC 时刻 - 8 个字节将表示它可以达到非常精细的分辨率，只要您可能需要即可。
尽管如此，您需要注意保持有效性 - 如果重复 session 今天发生变化，那在过去发生时不会发生变化...所以您可能还希望拥有关于实际发生复发时间的规范只读数据。显然，您不希望它永远保留过去，因此您可能希望“垃圾收集”超过几年的事件，具体取决于您的存储限制。
您可能还需要能够在每次发生时添加注释和异常(exception)情况(例如，“由于公共(public)假期，今天没有开会”或“移至下午 4 点”)。当您更改重复周期时，这变得真的有趣 - 如果您将“每周一”更改为“每周二”，您是否保留异常(exception)情况？当您从“每天”更改为“每周”时，您如何匹配异常？这些不是与存储直接相关的问题 - 但存储决策将影响实现您决定的任何策略的难易程度。
关于c# - 构建日历应用程序时，我应该在数据库中存储日期或重复规则吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4239871/