我正在寻找重复活动的解决方案，到目前为止我找到了两种方法：
为每个事件创建一个实例，因此如果用户有一年的每日事件，则表中需要365行。 对于固定的时间范围来说听起来似乎是合理的，但是如何处理没有结束日期的事件呢？
创建一个Reccuring模式表，使用某种时态表达式（Martin Fowler）在运行时创建未来事件。
有没有理由不选择第一种方法而不是第二种方法？ 第一种方法是过度填充数据库并可能影响性能，对吧？！
关于第1号方法的引用说：
“将重复出现的事件存储为单个行是灾难的一种方法。” （https://github.com/bmoeskau/Extensible/blob/master/recurrence-overview.md）
你们怎么看待它？我想了解为什么那会是一场灾难。
我赞美你的帮助
答案 0 :(得分：4)
正确的答案是两者，不是或。
暂时搁置没有重复结束日期的问题：你想要的是一个包含整个模式的重复规则的标题。这样，如果您需要更改模式，您就可以在单个记录中捕获该模式，该记录可以编辑而不会有更新异常的风险。
现在，加入SQL中的某种重复模式将是一个巨大的痛苦。此外，如果您的规则允许您调整（编辑，甚至删除）此重复模式的特定实例，该怎么办？
你怎么处理这个？您必须创建一个实例表，每个重复实例有一行，并且链接（外键）返回到用于创建它的单个规则。如果您需要编辑（或删除）整个模式，您可以修改单个孩子而不会忽视其来源。
考虑使用Outlook或Google日历等日历工具。这些应用程序使用此方法。您可以移动或编辑实例。您也可以更改整个系列。当您进入编辑模式时，应用程序会询问您的意思。
这有一些限制。例如，如果您编辑实例然后编辑模式，则需要有一个规则，表明（a）新的父获胜或（b）修改的子项总是获胜。我认为Outlook和Google日历使用方法（a）。
至于为什么要明确记录每个实例，我能想到的唯一灾难性的事情就是如果你没有将链接恢复到原始的重复模式，那么你将拥有一个在一次行动中取消整个系列的时间到了。
回到没有结束日期 - 这可能是一个自由裁量权的情况，是勇敢的更好的部分，并使用某种经验法则，对你未来的延伸范围施加实际限制这样一个系列 - 或者你可能不会在模式中允许这种规则。强制结束模式并让规则的创建者担心在任何未来的点上扩展它。
答案 1 :(得分：3)
将日历活动存储为规则，而不仅仅是作为具体化事件。
将重复出现的事件存储为一行是灾难的一个因素，原因很明显，物化将在理想情况下具有无限长度。由于无法使用无限长度表，开发人员将尝试使用一些聪明的，不全面的技巧来模仿该行为 - 导致应用程序的行为不稳定。
我的建议：存储规则并实现它们并添加为行，仅在查询时 - 导致混合方法。
因此，您将有两个表存储您的信息，第一个用于存储规则，第二个用于存储从规则中的任何规则实现的行。表
一般准则可以是：
普通表格不足以存储您要保存的内容。当存储过程支持访问和修改时，最好保持在数据库中保存此类信息。