Populating event recurrences VS Querying calendar events based on recurrence rules 填充事件重复 VS 基于重复规则查询日历事件
Populating event recurrences VS Querying calendar events based on recurrence rules 填充事件重复 VS 基于重复规则查询日历事件
我正在为一位客户创建一个PHP/mySQL日历应用程序的规格说明。其中一个问题需要解决的是，根据规则设置重复事件的发生情况，例如“每年在5月的第一个周末”。客户希望能够设置规则，例如“每年3月至6月的第三个星期四发生”等等。\n客户要求能够定义这些规则，并且不预先将事件发生表的实例填充到未来的X年中。\n是否有任何现有的日历解决方案可以支持这种基于模式的重复事件？\n是否有任何日历系统根据这样的规则进行查询，而不是在创建或更新重复事件时使用参数来生成事件表中的实例？\n我目前正在阅读以下内容：\na. http://martinfowler.com/apsupp/recurring.pdf\nb. http://www.kanzaki.com/docs/ical/recur.html\nc. https://www.rfc-editor.org/rfc/rfc5545#page-37\nd. https://www.rfc-editor.org/rfc/rfc5545#section-3.8.5.3\ne. iCalendar \"Field\" list (for database schema based on iCalendar standard)\nf. What\'s the best way to model recurring events in a calendar application?\ng. http://en.wikipedia.org/wiki/ICalendar#Technical%5Fspecifications\nh. http://muddybranch.thejkgroup.com/2005/01/why-remove-icalendar-recurring-rules/\ni. Should I store dates or recurrence rules in my database when building a calendar app?\n
\n注意：此文章建议存储重复规则，并根据此规则存储硬实例，预计未来X个月。\n
\nj. Data structure for storing recurring events?\nk. Should I store dates or recurrence rules in my database when building a calendar app?\n
\ni. 将数据分为两部分：\"规范\"数据（重复规则）和\"服务\"（生成的日期；除了重新生成之外只读）。如果规范数据发生变化，在那时重新生成\"服务\"数据。对于无限重复，保留一些实例，如果用完则生成更多（例如，如果用户查看他们2020年的日历）。\n
\nl. Calendar Recurring/Repeating Events - Best Storage Method 带有模式和SQL的唯一回答\nm. https://github.com/tusharmath/sheql 用于重复日期的语言\nn. https://github.com/tplaner/When 这个看起来非常适合基于规则生成日期，包括RRULE的。