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