为日历应用程序布置数据库架构

Question

我想写一个日历应用程序.对于数据库架构来说,这是一个经常出现的问题.我想知道如何组织这个的一些意见.

如果用户创建了一个事件,并且输入它会在周一重复所有人,那会怎么样？我怎么能将所有这些存储在数据库中？我不能创造无限的事件.我只是在那里放一张包含相关信息的表格,以便我可以计算所有事件的去向吗？如果是这样,每次用户查看日历的新部分时,我都必须计算它们.如果他们翻了几个月,但他们有大量的经常性项目怎么办？

此外,架构需要处理用户单击某个项目并在序列中显示"在序列中编辑此项目"而不是序列中的所有项目.然后我将一个项目从序列中分离出来吗？

更新1

我根本没看过iCal.为了清楚起见,我认为保存允许您计算重复项目的信息,并将任何与序列不同的信息拆分是一种很好的方式来存储它以便能够传输它.但我认为在一个应用程序中,这将太慢,无法在所有地方进行日期数学运算.

Answer 1

我一直在努力解决同样的问题,而且我实际上是在玩弄上面提到的"缓存表"这个想法,但后来我遇到了一个似乎没有代表的替代方案(这里建议).

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

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

它似乎保持事件表的规范化,并避免拆分系列来处理异常.

Answer 2

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

我最终想出了一个半黑客解决方案.我创建了一个event_type列.在该专栏中,我有:"每日","每周","每月"或"每年".我还有一个start_date和一个end_date列.其他所有内容都在实际的后端代码中处理.

如果用户只编辑了一个事件,我从未尝试拆分事件.在这种情况下没有必要.但是,您可以通过更改第一个的end_date来分割事件,使用新的开始日期和原始的end_date创建新事件,最后为您刚刚选择编辑的事件创建新事件.这个过程最终会创建3个事件.

哈哈,我知道.我想不出当时处理这个问题的聪明方法.