kasikПочитал похожие темы, но все таки не нашел ответа.
Задача:
Есть сущность маршрута(номер маршрута, название маршрута, режим следования).
Режим следование в свою очередь делится:
- (1) ежедневно
- (2) по датам(нужно выбрать одну или несколько дат)
- (3) по дням недели (нужно выбрать один или несколько дней недели)
- (4) по типу дней (нужно выбрать только один тип - есть набор типов дней)
- (5) по чет.\нечетн.


Помниться когда делал прикладушку занятости аудиторий, там тоже были такие же списки.
В базе все свел к пункту 2.

Грубо говоря маршрут не может существовать вечно, он существует определенный период (например 10 лет :-)
Так вот, в течении этого времени режим следования может меняться.
Поэтому для меня было проще было бы оставить только "по датам", а все остальное вынести в приложение.
Т.е. в базе хранить только даты когда маршрут следует.
Если режим следования изменится или добавиться новый тип.
Вам не надо будет менять БД.
Да история режима следования маршрутов сохраниться. ;-)

БредятинаТолько "все остальное" лучше в БД, чем в приложении:)
Оно конечно так, но всего не предусмотришь.

На предыдущей работе была задача сбора данных.
Причем были разные периоды.
Ну например: до 5-го числа месяца следующего за отчетным (квартальные данные)
Это еще ничего.
А вот до 1-го понедельника месяца следующего за отчетным (полугодовые данные)... гораздо веселее.

В базе это вылилось в приращение дней, месяцев, лет.
И все равно надо ручками подправлять.

Так что самый простой способ - это сразу сформировать конкретные даты режима следования и если что потом их ручками править.
Ну например, если был форс-мажор.
Буран или гроза.

Бредятинаmad_nazgulОно конечно так, но всего не предусмотришь.
Вы же свели часть данных к п. (2) (к датам). Остальные данные и логика тоже обычно к чему-то сводятся, и хранятся в БД:)


Я не свел, они сами свелись. ;-)
А логика "цикличности" упирается в то, что "циклы" во все не циклы, да и периоды меняются каждый месяц.

БредятинаУ Росстата море этого веселья:)


Ну почти, только в другом государстве.
Причем периодичность сдачи могла меняться каждый месяц, но "навсегда". :-)

Бредятинаmad_nazgul... Так что самый простой способ - это сразу сформировать конкретные даты режима следования и если что потом их ручками править.
Ну например, если был форс-мажор.
Буран или гроза.
Да

Ага.

alexeyvgmad_nazgulТак что самый простой способ - это сразу сформировать конкретные даты режима следования и если что потом их ручками править.Это не то что самый простой, а и самый правильный: расписание марщрута и конкретная поездка конкретного поезда (машины и т.п.) - совершенно разные бизнес-сущности.

Ну скорее они соотносятся как план/факт.
Так что, по моему, проще планировать конкретную поездку (пусть она и будет совпадать с некоторым "циклом").
Чем мучиться с "циклами".

kasikпок речь о конкретной поездке речи не идет, такое не предусмотрено в ТЗ, нужно только организорвать хранение маршрута

Оно логикой задачи "подразумевается".
Проще иметь дело с конкретным единичным маршрутом, чем с абстракцией "цикла".
По своему опыту, любая задача связанная с расписанием при попытке хранить не конкретные даты, а "циклы", приводит к большому "геморрою".
Так что храните единичный маршрут с конкретной датой.
А то, что такие же маршруты совпадают с другими маршрутами, так это ничего страшного.
Повторю: Для любого "цикла" все равно рано или поздно нужно будет предусматривать исключения.
А исключений может быть очень много, причем их предусмотреть нельзя.
Лучше их сразу исключить. :-)

alexeyvgНужно всё таки отталкиваться от бизнес-процесса. Например, для подразделения, отвеающего за печать и распространение по станциям и кассам ЖД-расписаний, знать конкретные маршруты не нужно.

Если речь о автоматизации именно управления марщрутами, то понятно, сущность единичного маршрута обязательно нужна, но и расписание нужно, это же самостоятельная бизнес-сущность, это нужно для планирования, да и просто классификации маршрута, управления маршрутом.


Так я и про то же.
Просто единичный маршрут (план), планируется на конкретную дату.
А то что такие маршруты повторяются каждую неделю (в течении n-го времени) это уже логика, которую запихать в БД трудно.

alexeyvgmad_nazgulТак что, по моему, проще планировать конкретную поездку (пусть она и будет совпадать с некоторым "циклом").
Чем мучиться с "циклами".Это как календарь - нужна таблица-календарь с записями на каждый день, но это не исключает необходимости задания календарных правил, хотя бы чтоб генерить записи календаря.

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