Как спроектировать схему базы для приложения-расписания

[hell0w0rd]

Интересуют именно повторяющиеся события. С днями/неделями все ок.
У нас есть начальная дата и смещение, как-то так:

SELECT * FROM calendar WHERE DATEDIFF(start_date, CURRENT_DATE()) % repeat_offset = 0

Вроде можно получить задачи на сегодня. А что если у задачи повтор раз в месяц/год?
Я полагаю что можно хранить номер дня, а для года еще и номер месяца. Но что делать с 31 числом к примеру?
И главное как проектировать базу, нужно ли выделять в отдельную таблицу такие задачи?
Сейчас накидал только это:

CREATE TABLE `calendar` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `start_time` time NOT NULL,
  `end_time` time NOT NULL,
  `start_date` date NOT NULL,
  `repeat_offset` int(11) unsigned DEFAULT NULL,
  `subject_id` int(11) unsigned DEFAULT NULL,
  `archive` tinyint(1) DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `subject_id` (`subject_id`),
  CONSTRAINT `calendar_ibfk_1` FOREIGN KEY (`subject_id`) REFERENCES `subjects` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Но это покрывает только то, что можно расчитать по дням

 

[WMix]

яб добавил поле repeat_type:enum(day,week,month,year...) и искал бы по разному от типа
вдруг захочется каждый первый понедельник месяца

дополнительная табличка? типа cache незнаю, можно и готовый html на актуальную неделю иметь к примеру

 

[prolis]

При проектировании БД надо анализировать хранимые сущности. Например, что такое "повторяющееся событие" - это одна сущность, или несколько идентичных? Я думаю что все-таки несколько неидентичных сущностей, так как минимум дата проведения события у них разная, значит и храниться они должны вместе со свсеми событиями раздельно. Алгоритм повторения нужен только на этапе планирования событий, но не на анализе. Иначе крайне сложно будет посчитать например сумму занятых человекочасов по всем событиям в январе.

 

[ksnk]

imho, нужно хранить "расписание" - структуру, в которой юзер определит событие и отметит его как повторяющееся, разовое, по событию, дням недели и т.д. и "лог событий" - структуру с датой проведения события, ссылкой на само событие и репортом проведения. Все события "в будущем" при изменении "расписания" удаляются и перегенерируются на какое-то время (1 месяц) в будущее. Периодически (раз в месяц) нужно обновлять события из расписания.

Получать задачи на сегодня - из "лога". Юзер редактирует "расписание".

 

[Тугай]

Хотя и много букв, но можно черпать инфу тут Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Согласно документу организуется так:
duration - время через которое событие должно повторится - соответствует repeat_offset ТСа
repeat - сколько раз должно повторятся.

 

[hell0w0rd]

Вся сложность в том, что с днями - ясно, неделями - 7 дней, тоже, а вот месяц/год штука сложная, нельзя однозначно указать интервал в днях.
В принципе WMix на вопрос ответил, еще посоветовали к mongo присмотреться)

 

[Sad Spirit]

Вся сложность в том, что с днями - ясно, неделями - 7 дней, тоже, а вот месяц/год штука сложная, нельзя однозначно указать интервал в днях.
В принципе WMix на вопрос ответил, еще посоветовали к mongo присмотреться)

К Postgres'у ещё присмотрись, там полноценный тип данных interval есть.