Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Периодические события. Структура хранения. [IB6.x, FireBird]

без ника © (2006-09-11 14:40:00)
Необходимо хранить периодичски повторяющиеся события, вида: каждый день, каждый N день, каждый N-й день месяцы, каждую сб и вс.

Вопрос вот в чем - каково оптимальное решение? На мой взгляд
2 варианта :

1- хранить только описание этих событий.

2- хранить описание (п1) + сразу формировать даты срабатывания события.

Вариант 1. Мало информации для хранения событие ~ 1 запись, но очень проблематично получать даты наступления события в SQL.

Вариант 2. Придется всегда вводить дату до которой событие актуально, много данных на 1 событие (каждый день - уже 365 записей). Зато очень просто использовать в SQL.

Может какие еще варианты есть?

atruhin (2006-09-11 18:34:00) [1]
Ну тогда возможно мой вариант не подойдет, нужно анализировать задачу.

без ника (2006-09-11 18:00:00) [2]
Тут ситуация как раз противоположная: задача финансового планирования, т.е. определяем условия наступления события (т.е. его периодичность), период действия и делаем прогноз - собственно считаем примерные $ за период.

atruhin (2006-09-11 17:47:00) [3]
Ну вряд ли тебе нужен список событий которые могли произойти за месяц. Обычно нужны отработанные события с результатом выполнения, а это просто заносится в лог таблицу. Т.е. гораздо легче разделить запрос на событие, и результат события, т.к. если событие усложнится то придется изменять всю логику. Например у меня в программе используется генерация событий на скидки по дням недели, по времени, складам учета, местам отпуска, а логируется отдельно в одном месте.

без ника (2006-09-11 16:16:00) [4]
2 atruhin ©

Я понял, все возможные комбинации разворачиваются. Но я уже говорил, что тогда вывести события за период, допустим 1 месяц - проблематично.

Т.е. входные данные у нас даты (реальные), а в таблицах хранится как написано выше только признак, допустим Пн, вт или чет нечет и т.д. Для SQL это сложная задача.

atruhin (2006-09-11 16:05:00) [5]
Как видимо я не понятно объяснил. Я и предлагал почит вариант 2.1 только расширенный. Т.е. режим задается не в одном поле, а выбором непустого поля.
Получаем:
событие на сб, вс.
Event_time = null; event_date = null; event_week = 6;
Event_time = null; event_date = null; event_week = 7;
аналогично для дней месяца, набора дат.

Shaman_ (2006-09-11 15:58:00) [6]
>...учитываются дни недели, четные нечетные недели, разные месяцы
Если такая структура, то действительно лучше дать пользователю интерфейс задания произвольных интервалов времени срабатывания

Sergey13 (2006-09-11 15:50:00) [7]
> [10] без ника (11.09.06 15:45)
> Т.к. расчет конкретных дат проще делать как раз на Delphi.

Можно попробовать и ХП прикрутить - это было бы предпочтительней. Возможно УДФ-ку придумать какую-нить в помощь.

без ника (2006-09-11 15:45:00) [8]
периодичность как раз сложная, я просто не описывал все варианты. Там как раз учитываются дни недели, четные нечетные недели, разные месяцы и т.д. :) В общем попробую реализовать оба варианта, но склоняюсь всё же ко второму варианту. Т.к. расчет конкретных дат проще делать как раз на Delphi.

Sergey13 (2006-09-11 15:36:00) [9]
> [2] без ника (11.09.06 14:55)

Если периодичность толькотупая, т.е. через час, день, месяц, то 1 вариант предпочтительнее. Если присутствуют "каждую сб и вс", да еще с учетом праздников и т.п. второй вариант и не париться. Проще один раз расчитать и записать, чем каждый раз пересчитывать.
ИМХО.

Shaman_ (2006-09-11 15:22:00) [10]
Как [2] - Наверно правильней сказать [2].1 :)
тоесть вариант - Начальная дата/Режим
Но думаю и так все поняли

без ника (2006-09-11 15:11:00) [11]
Да да, весь минус как раз в том, что все время приходится ограничивать событие каким то преиодом, т.е. оно получается конечным.

Shaman_ (2006-09-11 15:07:00) [12]
у меня реализован механизм как в [2], с запросами пришлось помудрить, зато все логично правильно.
А вот такой вариант - "хранить описание (п1) + сразу формировать даты срабатывания события." я бы не использовал. Даты срабатывания на какой срок формировать будешь и с какой периодичностью? :)
Лучше делай по нормальному, как [2]

без ника (2006-09-11 15:06:00) [13]
2 atruhin ©

Вот при такой структуре сложновато написать запрос

например показать даты всех переодических событий за 1 год.

без ника (2006-09-11 15:03:00) [14]
пример данных для 1-го варианта:

EventID | FromDate | Mode ---------------------------- 1 | 11.10.06 | 0 ----------------------------

Пример для 2-го случая:

EventID | FromDate | ToDate | Мode ---------------------------------------- 1 | 11.10.06 | 13.10.06 | 0 ---------------------------------------- и появляется 2-я таблица EventID | EventDate ---------------------- 1 | 11.10.06 1 | 12.10.06 1 | 13.10.06

atruhin (2006-09-11 15:03:00) [15]
Например так:
первая таблица - Events - описание события.
вторая таблича eventstime
- event_ref - сыылка на событие
- event_time - время возникновения
- event_date - дата возникновения, если null то событие периодическое
- event_week - день недели в который возникает событие
- event_month - день месяца в который возникает событие (по моему это лишнее можно через день недели настроить периодичность)

А далее в программе находиш не пустое поле.

без ника (2006-09-11 14:55:00) [16]
Ну для 1-го варианта : Таблица Events примерно

EventID - ID события
FromDate - Дата начала события
Mode - Режим события. допустим Mode = 0 - каждый день. Mode = 1 - каждый P1 день месяца, Mode = 2 - каждый год. и т.д. ..
P1
...
...
PN

Т.е. каждое событие характеризует только одна запись.

Второй вариант. Добавить в Events поле ToDate - дата завершения события. И еще 1 таблицу EventsDate:

EventID ID события
EventDate дата

Sergey13 (2006-09-11 14:45:00) [17]
> [0] без ника (11.09.06 14:40)

Что-то туманно очень.
Хранить старое без разницы как, лишь было поле даты/времени. Вопрос, когда делать новую запись?

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »