为日历应用程序设计数据库架构

发布于 2024-10-11 11:48:29 字数 434 浏览 2 评论 0原文

我想写一个日历应用程序。确实是重复出现的项目给数据库模式的工作带来了麻烦。我希望得到一些关于如何组织这个的意见。

如果用户创建一个事件，并输入该事件在每个星期一重复，永远，该怎么办？我如何将所有这些存储在数据库中？我无法创造无限的事件。我是否只需在其中放置一个包含相关信息的表格，以便我可以计算所有事件的去向？如果是这样，每次用户查看日历的新部分时，我都必须计算它们。如果他们翻阅月份，但有大量重复出现的项目怎么办？

此外，当用户单击某个项目并显示“编辑序列中的此项”而不是序列中的所有项目时，架构需要进行处理。然后我是否要将一项从序列中分离出来？

更新 1

我根本没有看过 iCal。需要明确的是，我认为保存允许您计算重复项目的信息，并拆分任何与序列不同的信息是存储它以便能够传输它的好方法。但我认为在应用程序中，这太慢了，无法在各处进行日期数学计算。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

挽清梦 2024-10-18 11:48:30

我一直在努力解决同样的问题，实际上我正在考虑上面建议的“缓存表”想法，但后来我遇到了另一种选择（此处建议），但似乎尚未得到体现。

构建一个包含所有事件的表

EventID (primary key)
Description
StartDate
PeriodType - days, weeks, months, years
PeriodFreq - # of days, weeks, etc between events
EndDate
... other attributes that can be modified

，然后为这些事件添加一个例外表。该表使用复合键，由映射到事件表的 EventID 和用于选择系列中特定事件的实例 ID 组成。

EventID (key)
InstanceID (key)
InstanceDate - the modified date of the exception 
IsCancelled - a flag to skip this date when traversing the series
... other attributes that can be modified

它似乎使事件表保持标准化，并避免分割系列来处理异常。

I have been struggling with the same problem, and I was actually toying with the "cache table" idea suggested above, but then I came across an alternative (suggested here) that doesn't seem to have been represented yet.

Build a table containing all events

EventID (primary key)
Description
StartDate
PeriodType - days, weeks, months, years
PeriodFreq - # of days, weeks, etc between events
EndDate
... other attributes that can be modified

Then add a table for exceptions to these events. This table uses a composite key, made up of the EventID that maps to the event table, and an instance ID to pick the particular event in the series.

EventID (key)
InstanceID (key)
InstanceDate - the modified date of the exception 
IsCancelled - a flag to skip this date when traversing the series
... other attributes that can be modified

It seems to keep the event table normalised, and avoids splitting up series to handle exceptions.

回复收藏 0 原文

没企图 2024-10-18 11:48:30

我最近创建了一个日历应用程序，这是我面临的众多挑战之一。

我最终想出了一个半黑客式的解决方案。我创建了一个 event_type 列。在那一栏中，我有：每日、每周、每月或每年。我还有一个 start_date 和一个 end_date 列。其他一切都在实际的后端代码中处理。

如果用户只编辑一个事件，我从未尝试过拆分事件。在当时的情况下没有必要。但是，您可以通过更改第一个事件的结束日期来拆分事件，使用新的 start_date 和原始事件的 end_date 创建一个新事件，最后创建一个新事件对于您刚刚选择编辑的那个。此过程最终将创建 3 个事件。

黑客风格，我知道。我当时想不出一个巧妙的方法来处理这个问题。

回复收藏 0 原文

探春 2024-10-18 11:48:30

像往常一样将重复项目保留在事件表中，但使用适当的开始/结束日期标记为重复项目。

如果用户修改约会的单个实例，只需创建一个新事件，其“parentId”可能等于重复事件的 ID。

构建逻辑，使日历用具有匹配父 ID 的事件覆盖特定日期的任何重复事件。

您关于性能的问题基本上是旧的速度与存储问题。我真的不认为所需的计算会超出存储这么多约会的空间要求。只需阅读数据库优化 - 索引等。

回复收藏 0 原文

最美不过初阳 2024-10-18 11:48:30

您能否使用“缓存”表来桥接这两个世界，在该表中预先计算接下来 X 天的事件价值？

因此，三个表：

recurring_event_specs
one_time_events
cached_recurring_events

对于今天 X 天内日历的任何部分，您的查询将 UNION one_time_events 和 cached_recurring_events。

然后，如果用户尝试在未来 X 天以上查看日历的一部分，则只需进行动态日期计算。我想你可以找到一个可以满足大部分正常使用的健全的 X。

每当用户添加新的重复事件时，cached_recurring_events 表就需要通过 cron-job/scheduled-task 进行更新，并且可能每天离线更新一次。但仅限于没有创建新的重复事件的日子。

Could you bridge the two worlds with a "cache" table, in which you pre-compute the next X days worth of events?

So three tables:

recurring_event_specs
one_time_events
cached_recurring_events

For any part of the calendar within X days of today, your query will UNION one_time_events and cached_recurring_events.

Then you would only have to do on-the-fly date calculations if the user tried to look at a part of the calendar more than X days in the future. I imagine you could find a sane X that would cover the majority of normal use.

The cached_recurring_events table would need to be updated whenever a user adds a new recurring event -- and possibly once a day offline, by a cron-job/scheduled-task. But only on days when no new recurring event has been created.

回复收藏 0 原文