我正在尝试确定在MySQL数据库中存储事件时间的最佳方法。这些应该尽可能灵活,能够代表“单一事件”(在某个时间开始,不一定需要结束时间),“全天”和“多日”事件,重复事件,重复全天事件,可能是“本月第3个星期六”类型的活动等。
请建议一些经过验证的数据库方案。
答案 0 :(得分:5)
表:事件
这可能会有所帮助。它需要相当数量的代码才能解释重复的时间。必须忽略分辨率低于重复单位的部分时间字段。在本月的第3个星期六做这件事并不容易......只需要NthDayOfMonth信息来做这种功能。
与重复出现的地方所需的代码相比,这需要的数据库模式很简单。
答案 1 :(得分:4)
我参与了一个计划程序应用程序,它松散地遵循iCalendar标准(记录事件)。您可能需要阅读Apple RFC 2445发布的icalendar schema或此架构,以了解它们是否与问题相关。
我的数据库架构(当时未考虑重复/全天事件)
event (event_id, # primary key
dtstart,
dtend,
summary,
categories,
class,
priority,
summary,
transp,
created,
calendar_id, # foreign key
status,
organizer_id, # foreign key
comment,
last_modified,
location,
uid);
上表中的外键calendar_id
引用此
calendar(calendar_id, # primary key
name);
虽然organizer_id
引用了这个(其他属性,如公共名称等缺失)
organizer(organizer_id, # primary key
name);
另一个您可能感觉更具可读性的文档位于here
希望这会有所帮助
答案 2 :(得分:1)
你需要两张桌子。一个用于存储重复事件(表重复)和一个用于存储事件(表事件)。简单条目仅存储在事件表中。重复条目存储在重复事件表中,重复事件的所有单个条目也存储在事件表中。这意味着每次输入重复条目时,都必须输入所有单个结果条目。您可以通过使用触发器或作为业务逻辑的一部分来实现此目的。
这种方法的优点是,查询事件很简单。它们都在事件表中。如果没有在事件表中存储重复事件,您将拥有使系统变慢的复杂SQL或业务逻辑。
create table repeatevent (
id int not null auto_increment,
type int, // 0: daily, 1:weekly, 2: monthly, ....
starttime datetime not null, // starttime of the first event of the repetition
endtime datetime, // endtime of the first event of the repetition
allday int, // 0: no, 1: yes
until datetime, // endtime of the last event of the repetition
description varchar(30)
)
create table event (
id int not null auto_increment,
repeatevent null references repeatevent, // filled if created as part of a repeating event
starttime datetime not null,
endtime datetime,
allday int,
description varchar(30)
)
答案 3 :(得分:0)
cron的方式相同吗?以这种方式记录开始和结束时间。
答案 4 :(得分:-2)
使用datetime和mysql内置的NOW()函数。在流程开始时创建记录,更新跟踪流程结束时的结束时间的列。