数据库设计:时间表,包括重复
我需要开发一个支持“时间表”的应用程序。时间表示例:
- 2011年1月1日上午9点
- 2011年1月1日上午9点至上午10点
- 2011年1月1日起,每周一
- 上午9点 2011年1月1日至2011年2月1日,
- 每周一上午9点 1月起,每周一上午9点1, 2011 出现 10
- 次等。
如果您看过 Outlook 的计划程序,这基本上就是我所需要的。这是他们的用户界面的屏幕截图: http://www.question-defense.com/wp-content/uploads/2009/04/outlook-meeting-recurrance-settings.gif
我该怎么办在数据库中对此类信息进行建模?请记住,我还需要查询这一点,例如:
- 今天安排的活动是什么?
- 特定重复安排的事件的接下来 10 个日期/时间是什么?
- 等等。
我正在使用 PHP/MySQL,但我对替代解决方案持开放态度。建议?
I need to develop an application that supports "schedules". Example of schedules:
- Jan 1, 2011 at 9am
- Jan 1, 2011 from 9am to 10am
- Every Monday at 9am, from Jan 1, 2011
- Every Monday at 9am, from Jan 1, 2011 to Feb 1, 2011
- Every Monday at 9am, from Jan 1, 2011 for 10 occurrences
- etc.
If you have seen Outlook's scheduler, that's basically what I need. Here's a screen shot of their UI: http://www.question-defense.com/wp-content/uploads/2009/04/outlook-meeting-recurrance-settings.gif
How would I model such information in a database? Keep in mind that I also need to query this, such as:
- What are the scheduled events for today?
- What are the next 10 dates/times for a particular recurring scheduled event?
- Etc.
I'm using PHP/MySQL, but am open to alternative solutions. Suggestions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我个人的意见是单独创建所有事件,并指定开始日期和结束日期。然后为事件生成一个唯一标识符(可能是您创建的第一个事件的事件 ID)并将其分配给所有事件(以便您知道它们以某种方式链接)。
优点:
并且只创建一次)
事件,然后重建所有它们 - 删除并重新创建)
缺点:
< strong>-- 从此处附加--
建议模型:
表事件
id
big int (自动增量)ref_id
big int (这是一种外键到id)date_start
日期date_end
日期标题
stringsaved_recurrence
text假设您有一个每周三和周五重复 4 周的事件:
ref_id
=0 和saved_recurrence
=保存的 JSON 对象并获取使用的id(自动递增)ref_id
=id< /strong>ref_id
(saved_recurrence
此处可以为空)您现在应该有 8 个具有相同
ref_id
的事件(每周 2 个,持续 4 周)。这样就可以轻松获取任何日期间隔内的事件。当您需要编辑事件时,只需检查ref_id
即可。如果它是0,则它是单个孤立事件。如果没有,您有一个 ref_id,您可以搜索它来获取所有事件实例。My personal opinion is to create all the events separately, with a start and end date. Then generate a unique identifier for the event (perhaps the event ID of the first you create) and assign it to all events (so you know they are somehow linked).
Advantages:
and create them all only once)
event, and then rebuild them all - remove and re-create)
Disadvantages:
-- appended from here --
Proposed Model:
Table Event
id
big int (auto increment)ref_id
big int (this is kind of foreign key to the id)date_start
datedate_end
datetitle
stringsaved_recurrence
textImagine you have an event repeating 4 weeks every Wednesday and Friday:
ref_id
=0 andsaved_recurrence
=saved JSON object and get the id that was used (auto incremented)ref_id
=idref_id
(saved_recurrence
can be empty here)You should now have 8 events (2 every week for 4 weeks) that have the same
ref_id
. This way it's easy to fetch events in any date interval. When you need to edit an event, you just check forref_id
. If it's 0 it's a single isolated event. If not, you have a ref_id that you can search to get all event instances.