重复事件可能会有很多问题，让我强调一些我所知道的。

解决方案1 -没有实例

存储原始约会+复发数据，不存储所有实例。

问题:

当你需要的时候，你必须在一个日期窗口中计算所有的实例，成本很高 无法处理异常(即。你删除一个实例，或者移动它，或者更确切地说，你不能用这个解决方案这样做)

解决方案2 -存储实例

存储从1开始的所有内容，以及链接回原始约会的所有实例。

问题:

占用很大的空间(但是空间很便宜，所以很小) 必须优雅地处理异常，特别是在做出异常后返回并编辑原始约会时。例如，如果您将第三个实例向前移动一天，那么如果您返回并编辑原始约会的时间，在原始日期重新插入另一个实例，并保留已移动的实例，该怎么办?断开移动的那个?试着适当地改变移动的那个?

当然，如果不打算使用异常，那么任何一种解决方案都可以，基本上可以从时间/空间权衡方案中进行选择。

您可以直接将事件存储在iCalendar格式中，这允许无限重复、时区本地化等等。

您可以将这些存储在CalDAV服务器中，然后当您想要显示事件时，您可以使用CalDAV中定义的报告选项，要求服务器在所查看的时间段内扩展重复出现的事件。

或者你可以自己将它们存储在数据库中，并使用某种iCalendar解析库来进行扩展，而不需要PUT/GET/REPORT与后端CalDAV服务器进行对话。这可能是更多的工作-我相信CalDAV服务器隐藏的复杂性在某个地方。

从长远来看，以iCalendar格式保存事件可能会让事情变得更简单，因为人们总是希望将它们导出，以便放在其他软件中。

您可以将事件存储为重复的，如果编辑了特定实例，则创建具有相同事件ID的新事件。然后，在查找事件时，搜索具有相同事件ID的所有事件以获得所有信息。我不确定您是否滚动了自己的事件库，或者您是否正在使用现有的事件库，因此可能无法实现。

查看下面的文章，了解三个优秀的ruby日期/时间库。 对于递归规则和事件日历需要的其他东西，Ice_cube似乎是一个可靠的选择。 http://www.rubyinside.com/3-new-date-and-time-libraries-for-rubyists-3238.html

对于准备支付一些授权费用的。net程序员，您可能会找到Aspose。网络很有用…它包括一个iCalendar兼容库，用于重复约会。

我开发了多个基于日历的应用程序，还编写了一组支持递归的可重用JavaScript日历组件。我写了一篇关于如何设计递归式的概述这可能对一些人有帮助。虽然有一些建议是针对我所编写的库的，但所提供的绝大多数建议都适用于任何日历实现。

以下是一些要点:

Store recurrence using the iCal RRULE format -- that's one wheel you really don't want to reinvent Do NOT store individual recurring event instances as rows in your database! Always store a recurrence pattern. There are many ways to design your event/exception schema, but a basic starting point example is provided All date/time values should be stored in UTC and converted to local for display The end date stored for a recurring event should always be the end date of the recurrence range (or your platform's "max date" if recurring "forever") and the event duration should be stored separately. This is to ensure a sane way of querying for events later. Read the linked article for more details about this. Some discussion around generating event instances and recurrence editing strategies is included

这是一个非常复杂的话题，有很多很多有效的方法来实现它。我要说的是，我实际上已经成功地实现了几次递归，并且我会谨慎地从那些没有实际使用过递归的人那里获得建议。