构建日历应用程序时，我应该在数据库中存储日期或重复规则吗？
我正在构建一个日历网站（ASP.NET MVC）应用程序（想想 Outlook 的简单版本），我想开始支持
现在我正在存储的 重复发生的日历事件（每月、每年等）我的实际日期，但我想弄清楚，随着重复，继续存储日期（有一些明显的截止）是否有意义，或者我应该存储重复选项并动态生成日期。
这让我开始思考 Outlook、Google Mail 等如何执行此操作或支持重复日历项目的任何其他服务。
对此有什么建议吗？
I am building a calendar website (ASP.NET MVC) application (think simple version of outlook) and i want to start supporting calendar events that are recurring (monthly, yearly, etc)
right now I am storing actual dates in my but I wanted to figure out if, with recurrence, does it make sense to continue to store dates (with some obvious cutoff), or should I store the recurrence options and generate the dates on the fly.
It got me thinking how outlook, google mail, etc does this or any other service that supports recurring calendar items.
Are there any suggestions on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您肯定需要存储其中一些。用户可能会编辑其中一个事件，而使其他事件保持不变（您可能会遇到这样的问题：“您想编辑所有重复事件还是仅编辑此事件？”在某些日历中，即 Windows Mobile）。
您可能还希望存储过去的事件，并且在用户删除重复事件时不删除它们。
如果您存储所有其他或生成它们是一个实现细节。如果可能的话，我更愿意生成它们。
在任何情况下，您都希望将一些重复事件的 ID 与每个事件一起存储，再加上一些标志来告诉您该事件稍后是否被修改。或者在更复杂的方法中，每个事件属性的标志告诉它是否是默认值（来自重复事件）或者是否针对该特定实例进行了修改。当用户决定编辑重复事件时，您将需要它。
You need to store some of them for sure. The user might edit one of the events, leaving others untouched (you probably met the question: "Do you want to edit all recurring events or only this one?" in some calendars, ie. Windows Mobile).
You also might want to store past events and not remove them when the user deletes the recurring event.
If you store all others or generate them is an implementation detail. I would prefer to generate them, if possible.
In any case you'll want to have some ID of the recurring event stored with each event, plus some flag telling you if the event was modified later. Or in more complicated approach, a flag for each event property telling, if it's default value (from the recurring event) or if it was modified for this particular instance. You'll need this when the user decides to edit the recurring event.
将数据分为两部分：“规范”数据（重复规则）和“服务”（生成日期；除了重新生成之外是只读的）。如果规范数据发生变化，则在该点重新生成“服务”数据。对于无限重复，请保留一定数量的实例，并在用完时生成更多实例（例如，如果用户查看 2030 年的日历）。
如果您的处理器速度无限，则只需要规范数据 - 但实际上，对每个页面视图上的所有重复规则进行所有日期/时间处理可能太时间了 -消耗......所以你需要权衡一些存储（和复杂性）来节省重复的计算。与大量事件所需的计算相比，存储通常相当便宜。如果您仅需要存储事件的日期，那确实非常便宜 - 您可以轻松地使用 4 字节整数来表示日期，然后从中生成完整的日期/时间，假设您的重复都是基于日期的。对于基于时间的重复（例如“每三个小时”），您可以完整的 UTC 时刻 - 只要您可能需要，8 个字节将表示为非常精细的分辨率。
不过，您需要小心保持有效性 - 如果定期会议今天发生变化，则在过去发生时不会改变......所以您可能想要还拥有关于实际重复发生时间的规范只读数据。显然，您不希望它永远保留过去，因此您可能希望“垃圾收集”几年前的事件，具体取决于您的存储限制。
您可能还需要能够在每次会议的基础上添加注释和例外情况（例如，“由于公共假期，今天没有举行会议”或“移至下午 4 点”）。当您更改重复周期时，这会变得非常有趣 - 如果您将“每周一”更改为“每周二”，您是否保留例外情况？当您从“每天”更改为“每周”时，您如何匹配例外情况？这些不是直接与存储有关的问题 - 但存储决策将影响实施您决定的任何策略的难易程度。
Separate your data into two parts: the "canonical" data (the recurrence rule) and "serving" (generated dates; read-only aside from regeneration). If the canonical data changes, regenerate the "serving" data at that point. For infinite recurrences, keep some number of instances and generate more if you run out (e.g. if the user looks at their calendar for 2030).
If you had infinite processor speed, you'd only need the canonical data - but in reality, doing all the date/time processing for all the recurrence rules on every page view is likely to be too time-consuming... so you trade off some storage (and complexity) to save that repeated computation. Storage is usually pretty cheap, compared with the computation required for a large number of events. If you only need to store the dates of the events, that's really very cheap - you could easily use a 4 byte integer to represent a date, and then generate a complete date/time from that, assuming your recurrences are all date based. For time-based recurrences (e.g. "every three hours") you could full UTC instants - 8 bytes will represent that down to a pretty fine resolution for as long as you're likely to need.
You need to be careful about maintaining validity though - if a recurring meeting changes today, that doesn't change when it has happened in the past... so you probably want to also have canonical read-only data about when recurrences actually occurred. Obviously you won't want that to keep the past forever, so you probably want to "garbage collect" events more than a few years old, depending on your storage limitations.
You may also need the ability to add notes and exceptions (e.g. "meeting doesn't occur today due to a public holiday" or "moved to 4pm") on a per-occurrence basis. That becomes really fun when you change the recurrence - if you change "every Monday" to "every Tuesday" do you keep the exceptions or not? How do you even match up the exceptions when you change from "every day" to "every week"? These aren't questions which are directly about storage - but the storage decisions will affect how easy it is to implement whatever policy you decide on.
您将需要单独处理事件和事件。
事件明智：
对于事件，您需要存储重复规则（可以是 rfc5545 指定的 rrule，也可以是 rfc5545 中的 rdate 等明确的日期集），但也需要存储例外（请参阅 rfc5545 的 exdate 以及可能的 rfc2445 中的 exrule）。
您还需要跟踪这些规则的变化：
rdate、exdate 中的更改在将来发生时没有问题，而对于过去的日期则可以忽略。
rrule 的更改更加棘手，因为它会影响之前发生的事件。我个人的偏好是为旧规则和新规则添加特定属性，以指定它们各自的有效期开始和结束日期。
如果事件的时间跨度有限（例如 COUNT 或 UNTIL 属性存在），您应该将其开始和结束存储在表中，以便更轻松地查询事件（特别是在查找预先计算的时间窗口之外的事件时（见下文），它可以帮助减少需要重做计算的事件数量）。
明智的发生情况：
对于发生的情况，您应该将实例存储在围绕当前的预定义窗口内（例如+/- 6个月或12个月并定期计算）并保留记录，以便在您的用户希望将来看到更多情况时允许重新计算（例如性能问题）。您还应该考虑计算索引（RECURRENCE-ID）以帮助更轻松地查找下一个出现的情况。
后端较少，但前端较多，您还应该跟踪 tzid 更改，以询问用户是否在给定 tzid 上安排的事件是否需要保留在当前时区更新（想想萨摩亚岛的某个人，在该国决定不存在这一天之前，他已安排在 2011 年 12 月 30 日星期五举行会议），类似地，您可以询问在夏令时期间发生的事件是否意味着“永远不会发生”或“发生两次”（有关此主题的更多信息此处）
笔记：
您可能需要考虑超出 rfc5545 中定义的重复规则的支持，并添加对宗教重复规则的支持（参见 USNO 对日历的介绍 或印刷版“日历计算”（第三版）
E. Reingol 和 N. Dershowitz）。
既然您询问现有的实现，您可以轻松检查 sunbird (sqlite) 或 Apple 的数据库架构开源日历和联系人服务器，提供了 caldav 服务器现有开源项目的更完整列表（这可能是您正在寻找的内容的子集）此处）
You will need to handle separately events and occurrences.
EVENT WISE:
For events, you will need to store recurence rules (which can be an rrule like specified by rfc5545 but also an explicit set of dates like rdate in rfc5545) but also exceptions (see exdate of rfc5545 and possibly exrule as in rfc2445).
You will also need to keep track of changes in those rules:
Changes in rdate, exdate are no problem when they occur in the future and to be ignored for past dates.
Changes in rrule are more tricky as impacting previous occurences. My personal preference is to add a specific property for the old and new rrule to specify their respective start and end date of validity.
if the event has a limited time span (say COUNT or UNTIL property are present) you should store its start and end in your table to allow easier querying of events (especially when looking for occurrences outside your precalculated time window (see below), it can help reduce the number of events for which the computation is to be redone).
OCCURRENCES WISE:
for occurences you should store instances within a predefined window around present (say +/- 6 months or 12months and computed on a regular basis) and keep records of this to allow re-calculation if your users want to see further in the future (for performances issues). you should also consider computing the index (RECURRENCE-ID) to help easier finding of the next occurrence.
less on the back-end but more on the front-end you should also keep track of tzid changes to ask the user if an event which was scheduled on a given tzid if it is meant to stay on current time zone of it needs to be updated (think of someone in Samoa island which had schedule a meeting on Friday, Dec. 30 2011 before the country decided this day would not exist), similarly you can ask if an event which happens during the daylight saving time is meant to "never happen" or "happen twice" (more on this topic here)
Note:
you may want to consider support beyond what is defined in rfc5545 in terms of recurence rules and also add support for religious recurring rules ( see USNO introduction to calendars or in print "Calendrical Calculations" (Third Edition) from
E. Reingol and N. Dershowitz).
Since you ask about existing implementation, you can check easily the database schema of sunbird (sqlite) or of the Apple open source Calendar and Contacts Server, a more complete list of existing open source projects for caldav servers (which is probably a subset of what you are looking for) is available here)
我必须建立一个与日程安排配合使用的系统，我们两者都做到了。这是我们有
通过安排，事情可能会变得非常棘手，因为您必须记住，在任何时间点，安排都可能发生变化。此外，当您的应用程序未运行时，某个项目可能会到期，当应用程序再次启动时，您需要知道如何识别逾期项目。
此外，我们还确保跟踪实际时间表的表是独立的。原因是这些是系统中最复杂的表集，我们希望能够重用它们，以便它们可以用于需要调度的不同事物。例如发送管理电子邮件、发送通知以及清理日志文件等服务器维护。
I had to build a system that worked with scheduling and we did both. Here's what we had
With scheduling, things can get really tricky because you have to remember that at any point in time, the schedule can change. Also, an item may be due when your application is not running, and when it starts up again, you need to know how to identify past due items.
Also, we made sure that the tables that kept track of the actual schedule stood alone. The reason for this is that those were the most complex set of tables in the system and we wanted to be able to reuse them so that they could be used for different things that needed scheduling. Such as sending admin emails, sending notifications, and server maintenance like cleaning up log files.
我肯定会使用你的第二个选择。使用不同的重复选项，单独存储并动态计算。存储所有这些日期将产生大量不必要的数据。
这是一个很好的答案来补充您的问题。
用于存储重复事件的数据结构？
另外，作为旁注。我已开始将所有内容存储为 UTC 时间，以便在您需要使用多个时区时拥有共同的基准。
I would definitely use your second option. Use different recurrence options, store it separately and calculate on the fly. Storing all those dates would be a boatload of data that is not necessary.
Here's a good answer to compliment your question.
Data structure for storing recurring events?
Also, as a side note. I've started storing everything as UTC time so that you have a common baseline if you ever need to use multiple timezones.
请注意，大多数回复倾向于保存生成的数据。但请务必考虑您的用例。
以前我的服务器受到 io 的限制，很多 cpu 无所事事。现在你有SSD（如果你能买得起的话，否则你就只剩下一个旧的旋转硬盘）但请注意核心数量也增加了。
此类计算的好处在于，您可以轻松地拆分它们，并将它们分配给您的许多核心，甚至本地网络中的一些廉价服务器。通常比设置 nosql 集群或采用完整数据库集群方式便宜。
替代方案也可能是缓存，只需缓存您的日历视图，无需每次在没有任何更改时进行所有计算。
但正如所说，这取决于您的用例。不要只遵循上面的答案，如果你有时间，可以自己计算一下然后做出决定。
Note that most replies lean toward saving generated data. But make sure you consider your use case.
Back in the days my servers were limited by io with a lot of cpu doing nothing. Nowadays you have ssd (if you can afford those, otherwise your left with an old spinning hd) but note that core count has increased too.
The nice thing about these kind of calculations is that you can split them easily and give them to your many cores or even to a few cheap servers in a local network. Often cheaper than setting up a nosql cluster or going the full database cluster way.
And alternative might also be a cache, just cache your calendar view, no need to do all the calculations every time when nothing has changed.
But as said it depends on your use case. Don't just follow the above answers but do your own calculations if you have time and than make a decision.
我在几年前制作的网络应用程序中遇到了类似的问题（现在可能有更好的方法:)）。我想包含一个调度程序，它具有重复事件的所有功能，处理时间、天、周、月、年和例外，这样我就可以制定如下规则：
1）每天上午 10 点（星期三除外
）2）每 2 小时每天最多 4 次迭代
3) 每个月的第一个星期一
等。
存储重复的日期/时间是可能的，但不灵活。事件的每次迭代都会在“最大值”出现时发生变化。您的未来展望有多远？
最后，我编写了一个可以读取和写入字符串的自定义调度类。这是存储在数据库中的字符串，然后可以调用一个简单的函数来找出下一次出现的时间。
I had a similar problem in a web-application I made a few years ago (there may well be a better way now :) ). I wanted to include a scheduler which had all the functionality of recurring events, handle time, days, weeks, months, years, and exceptions, so that I could have rules like:
1) Every Day at 10am excepted Wednesdays
2) Every 2 hours with a maximum of 4 iterations per day
3) Every First Monday of the Month
etc..
Storing the recurring dates/times was possible, but inflexible. Each iteration of your event changes when the "maximum" would be. And how far ahead do you look?
In the end I wrote a custom scheduling class that could read from and write to a string. This was the string that was stored in the database and then a simple function can be called to find out when the next occurrence is.