在构建日历应用程序时，我应该在我的数据库中存储日期或重复规则吗? [英] Should I store dates or recurrence rules in my database when building a calendar app?

问题描述

我正在构建一个日历网站 (ASP.NET MVC) 应用程序(想想 Outlook 的简单版本)，我想开始支持重复出现的日历事件(每月、每年等)

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.

这让我想到了 Outlook、谷歌邮件等是如何做到这一点的，或者任何其他支持定期日历项目的服​​务.

It got me thinking how outlook, google mail, etc does this or any other service that supports recurring calendar items.

对此有什么建议吗?

推荐答案

将您的数据分为两部分:规范"数据(重复规则)和服务"(生成日期；除了重新生成之外只读).如果规范数据发生更改，请在该点重新生成服务"数据.对于无限重复，保留一些实例并在用完时生成更多实例(例如，如果用户查看 2020 年的日历).

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 2020).

如果您有无限的处理器速度，您只需要规范数据 - 但实际上，对每个页面视图上的所有重复规则进行所有日期/时间处理可能是太费时了……所以你要牺牲一些存储(和复杂性)来保存重复的计算.与大量事件所需的计算相比，存储通常非常便宜.如果您只需要存储事件的日期，那真的非常便宜 - 您可以轻松地使用 4 字节整数来表示日期，然后从中生成完整的日期/时间，假设您重复都是基于日期的.对于基于时间的重复(例如每三个小时")，您可以使用完整的 UTC 瞬间 - 只要您可能需要，8 个字节就可以将其表示为非常精细的分辨率.

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.

您可能还需要能够逐次添加注释和例外情况(例如，由于公共假期，今天没有举行会议"或移至下午 4 点").当您更改重复时，这变得真的有趣 - 如果您将每个星期一"更改为每个星期二"，您是否保留例外情况?当您从每天"变为每周"时，您甚至如何匹配异常?这些不是直接与存储有关的问题 - 但存储决策将影响实施您决定的任何策略的难易程度.

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.

这篇关于在构建日历应用程序时，我应该在我的数据库中存储日期或重复规则吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！