Мне необходимо сделать расписание событий, с возможностью создания периодичных событий (день, неделя, месяц, год), аналог Google Календарь

Подскажите, как лучше это реализовать, чтобы максимально использовать СУБД, т.е. делать поиск запросом, а не программно вычислять дату и время события.
Может кто-то подскажет примеры таких решений

Здравствуйте, beevasya, Вы писали:

B>Мне необходимо сделать расписание событий, с возможностью создания периодичных событий (день, неделя, месяц, год), аналог Google Календарь

B>Подскажите, как лучше это реализовать, чтобы максимально использовать СУБД, т.е. делать поиск запросом
, а не программно вычислять дату и время события.


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

Здравствуйте, Sshur, Вы писали:

S>Ну тогда делайте таблички справочник_событий (ид, информация о расписании события, данные события) и расписание_событий (дата, ид события). Какой-то процесс (джоб например) должен периодически запускаться (например раз в день) и заполнять расписание на основании справочника. Пользователи же будут заполнять справочник. В общих чертах все.

Ну при таком подходе достаточно сложно реализовать ежедневное событие без даты окончания.
Можно ограничиться определенной датой (например 01.01.2100 год), но это громоздко, может есть какие-то красивые решения?
На сколько я понял в iCalendar это реализуется набором правил, но как их перенести в БД, с возможностью поиска?

Здравствуйте, beevasya, Вы писали:

B>Здравствуйте, Sshur, Вы писали:

S>>Ну тогда делайте таблички справочник_событий (ид, информация о расписании события, данные события) и расписание_событий (дата, ид события). Какой-то процесс (джоб например) должен периодически запускаться (например раз в день) и заполнять расписание на основании справочника. Пользователи же будут заполнять справочник. В общих чертах все.

B>Ну при таком подходе достаточно сложно реализовать ежедневное событие без даты окончания.

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

Вам искать надо вперед или назад? И как далеко?

B>Можно ограничиться определенной датой (например 01.01.2100 год), но это громоздко, может есть какие-то красивые решения?
B>На сколько я понял в iCalendar это реализуется набором правил, но как их перенести в БД, с возможностью поиска?

Если отталкиваться от набора правил — то надо четко хранить историю их изменения, чтобы потом расписание задним числом не менялось.

В принципе, можно хранить только правила, а расписание всякий раз считать. Но тогда поиск по расписанию будет более ресурсоемким

Здравствуйте, beevasya, Вы писали:

B>Мне необходимо сделать расписание событий, с возможностью создания периодичных событий (день, неделя, месяц, год), аналог Google Календарь

B>Подскажите, как лучше это реализовать, чтобы максимально использовать СУБД, т.е. делать поиск запросом, а не программно вычислять дату и время события.
B>Может кто-то подскажет примеры таких решений

(дата - первая дата события) mod длина периода == 0

Правда, переводы на зимнее/летнее время все портят.

Здравствуйте, Lloyd, Вы писали:

L>

L>(дата - первая дата события) mod длина периода == 0
L>

L>Правда, переводы на зимнее/летнее время все портят.

Не совсем понял идею, но с переводом часов легко можно справиться, если хранить даты в UTC.

Здравствуйте, Sshur, Вы писали:

S>Не совсем понял идею, но с переводом часов легко можно справиться, если хранить даты в UTC.

Не всё так просто с UTC.

2010-10-10 в 17:00 местного времени в Новосибирске создаём задачу: каждый день в 7:00 проиграть mp3’шку. OK, при создании события произошла конвертация в UTC: первая дата события — 2010-10-11T00:00Z, периодичность P1D, итого, формула события — R/2010-10-11T00:00Z/P1D (в терминах ISO 8601). Ну и с 11 по 30 октября мы нормально просыпаемся в 7 часов утра.

Однако, в 2010-10-31T03:00+0700 часы переводятся на зимнее время — 2010-10-31T02:00+0600. 31-го числа нас будят в 6 утра. Fail.

Ну или 24-го октября нас занесло в Красноярск. Местное время UTC+8, событие происходит в 2010-10-24T08:00+0800. Опять fail, мы проспали.

Собственно, мысль, которую хотелось донести: есть события, которые должны переходить вместе с пользователем в другие часовые пояса, как из-за летнего времени, так и из-за смены географического положения. И есть события, которые не должны.

Здравствуйте, Centaur, Вы писали:

C>Здравствуйте, Sshur, Вы писали:

C>Собственно, мысль, которую хотелось донести: есть события, которые должны переходить вместе с пользователем в другие часовые пояса, как из-за летнего времени, так и из-за смены географического положения. И есть события, которые не должны.

Да, будильник по UTC это fail. Ну а если топикстартеру надо строго раз в час выключать ядерный реактор, то UTC ему поможет

Я сам все больше навигационными задачами занимаюсь, тут без универсального времени никуда..

Здравствуйте, Sshur, Вы писали:

C>>Собственно, мысль, которую хотелось донести: есть события, которые должны переходить вместе с пользователем в другие часовые пояса, как из-за летнего времени, так и из-за смены географического положения. И есть события, которые не должны.

S>Да, будильник по UTC это fail. Ну а если топикстартеру надо строго раз в час выключать ядерный реактор, то UTC ему поможет

Да, а если надо каждый день в 16:00 звонить жене — то задача должна жить по времени жены. В том числе, если мы оказались в поясе, не переходящем на летнее время, а она — в переходящем. Или если наш и её пояса переходят на летнее время по разным правилам.

Ситуация несколько иная, надо на основе запроса к БД определить попадает ли конкретная дата в периодическое расписание
т.е. есть события и есть конкретная дата, нужно без программного участия определить входит ли данная дата в повторения
если реализовывать повторения в виде правил, то все правила надо обрабатывать программно, хотелось бы решение только на основе запросов

Но общий обзор темы показал что только средствами СУБД это не реализовать
Конкретную дату надо будет прогонять по всем правилам программно

Здравствуйте, beevasya, Вы писали:


B>Но общий обзор темы показал что только средствами СУБД это не реализовать
B>Конкретную дату надо будет прогонять по всем правилам программно

в СУБД сейчас можно хорошо писать процедуры. Я кстати писал такое, нужно было именно средствами MSSQL 2005 проверять попадает ли дата в определенное событие — задаваемое временем начала и конца. События были периодические по шаблону типа 0100000001000, где каждый знак — это временной интервал, например час, а 1 или 0 — происходит ли событие в данный час или нет. Шаблон соответственно повторяется начиная с определенной даты.

В общем, я написал clr функцию, которая на основании даты начала и шаблона возвращала табличку с отдельными событиями, где каждая строка (время начала, время конца). Дальше проверить попадает ли дата в диапазон — дело техники. Причем, проверки были как на клиенте, так и на сервере — удобство было в том, что код использовался один и тот же.