Лучший способ сохранить времена события в (Моей) базе данных SQL

Таблица: события

• StartTime (дата и время)
• EndTime (дата и время) пустой указатель в течение никакого времени окончания
• RepeatUnit (международный) пустой указатель = noRepeat, 1 = час, 2 = день, 3 = неделя, 4 = dayOfMonth, 5 = месяц, 6 = год
• NthDayOfMonth (интервал)
• RepeatMultiple (интервал), например, устанавливает RepeatUnit на 3 и это к 2 в течение каждых двух недель
• Идентификатор - при необходимости, StartTime мог бы подойти, чтобы Вы однозначно определили событие.
• Имя (строка) - называет данными событию при необходимости

Это могло бы помочь. Это потребовало бы, чтобы достойный объем кода интерпретировал, когда повторения. Должны были бы быть проигнорированы части полей времени, которые являются в более низких разрешениях, чем повторная единица. При выполнении 3-й субботы месяца woudln't быть легкой любой... информация о NthDayOfMonth требовалась бы только для того, чтобы сделать этот вид функциональности.

Схема базы данных, требуемая для этого, проста по сравнению с кодом, требуемым разрабатывать, где повторения падают.

Тем же путем крон делает это? Запись и запускает и время окончания тот путь.

Я работал над приложением планировщика, которое свободно следует iCalendar стандарту (для записи событий). Можно хотеть считать RFC 2445 или эту схему, опубликованную Apple Inc. icalendar схема, чтобы видеть, относятся ли они к проблеме.

Моя схема базы данных (recurring/whole-day событие не был рассмотрен в то время),

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); 

Другая документация, которую можно найти более читаемым, расположена здесь

надеюсь, это поможет

Используйте дату и время и mysql's, встроенный ТЕПЕРЬ () функция. Создайте запись, когда процесс запускается, обновите свой столбец, который отслеживает время окончания когда это концы процесса.

Вам нужны две таблицы. Один для хранения повторяющихся событий (таблица repeatevent) и один для хранения событий (событие таблицы). Простые записи только хранятся в конечном счете таблица. Повторяющиеся записи хранятся в repeatevent таблице, и все однократные въезды для повторяющегося события также хранятся в конечном счете таблица. Это означает каждый раз ввод повторяющейся записи необходимо ввести все единственные получающиеся записи. Можно сделать это при помощи триггеров, или как часть бизнес-логики.

Преимущество этого подхода, те запросы, события просты. Они - все в конечном счете таблица. Без устройства хранения данных повторяющихся событий в конечном счете таблица, у Вас были бы сложный 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)
)