Собственно хотелось бы найти типовое решение следующей задачи:
Фактически в большинстве поручений и планах указываются не конкретные даты, а их "условные заменители". Например, "за 3 дня до окончания месяца", "в течение 5 рабочих дней с начала квартала" и т.п. Также такие задачи могут иметь определённую повторяемость ("ежемесячно", "ежегодно в первый квартал" и т.д). В таких случаях было бы логичнее хранить в базе данных условия формирования или расчёта таких дат. Т.е. будут примерно такие поля как: ТипИнтервалаДат (день, месяц...), Количество (знак минус - обратный отсчёт), ПризнакРабочихДней (чтобы заджойнить на таблицу с рабочим календарём), ПризнакОтсчёта(предыдущий или последующий месяц) и т.д.

Как решается такая задача в лучших практиках?

Модератор: Тема перенесена из форума "Microsoft SQL Server".

Кот Матроскин"ПризнакРабочихДней" - это плохая идея.
Лучше хранить ссылку на конкретный календарь.
Для универсального решения не может быть конкретики. Простая функция будет искать дату в какой-то условной таблице с выходными/рабочими днями, которая отстоит от указанной на заданное количество дней.
Таблица с выходными может быть разной: Кто-то хранит только выходные и укороченные дни, кто-то все дни с дополнительным битовым полем "Выходной", кто-то наоборот хранит только рабочие дни...

ПризнакРабочихДней - это чисто указатель, что поле вычисляемое из таблицы с табель-календарём.

Идея такая:
берём некоторое количество(number) временных интервалов(datepart ) от некоторого временного интервала(date).

Аналогично с функцией DATEADD (datepart , number , date ),
где date также предварительно вычисляется от заданной даты (текущий месяц, предыдущий день, следующий год и т.п.)

По сути нужен некий шаблон для автоматического расчёта сроков исполнения поручений.

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

Кот МатроскинДенис БПризнакРабочихДней - это чисто указатель, что поле вычисляемое из таблицы с табель-календарём.

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

Злой БобрПоскольку тема в ветке о проектировании БД, то предположу что интересует как именно (в виде каких таблиц) это хранится в БД. Собственно создаете таблицу с вашими периодичностями (id, name) (..., "за 3 дня до окончания месяца", "в течение 5 рабочих дней с начала квартала" и т.п.). В таблице с приказом делаете поле с ИД этой таблицы. Если необходимо то в отчетах аналогично. Дальше уже дело за приложением.
В таком случае пользователь будет удручён перспективой выбирать из +100500 вариантов и будет часто ошибаться. Плюс проблему по расчёту конкретной даты нужно будет всё равно решать, т.е. таблицы (id, name) явно недостаточно, так как где-то нужно держать конкретную формулу для расчёта даты по конкретному id, или же где-то каким-то образом парсить строку name.
Есть ещё фразы, связывающие сроки исполнения с другой задачей из того-же шаблона документа. Я предполагаю, что необходимо хранить ИД родительского(или инициализируещего) мероприятия. По которому также можно отдельной функцией отсчитать временной интервал.

[quot Кот Матроскин]Денис Б.представьте, что в этой таблице помимо поля "дата" есть поле "ID календаря", и лежат выходные дни для России (один ID), Украины (другой ID) и США (третий ID). Вот этот ID я и предлагаю указывать в ссылке.
При таком раскладе действительно можно и нужно хранить "ID календаря".

(пошутю)p.s. Некоторые свидомитые страны наверное так и делают, и хранят ID календаря Крыма (на всякий случай).
(пошутю2) Жалко, что ограничения SQL-сервера не позволяют хранить ещё "ID календарной системы", а то бы ещё календарь Майя или друидов можно было учесть.

По календарям, я считаю, можно закончить с того, чем и начиналось:
Хранится только признак того, что возможен "сдвиг" даты и его расчётом должна заниматься некая функция. Она сама должна знать какой и где взять календарь и что из-него извлечь.

Про всякие ИДкалендарей можно смело забыть. И даже если предполагать, что может быть несколько календарей рабочих дней для разных стран, то это не верно, так как организация может быть куплена или перейти под юрисдикцию другого государства. Да что там говорить о разных странах... у нас в субъектах также есть национальные праздники. А ещё... в коллективном договоре организации может быть прописан выходной день в день рождения, для молодых родителей - 1 сентября и т.д.

softwarerСходу очевидно, что речь идёт о наличии некоего (потенциально расширяемого) списка функций. Более того, по опыту, клиенты любят такие вещи кастомизировать (скажем, добавлять какой-нибудь "в следующий рабочий понедельник после...") По бизнес-логике от этой структуры данных требуется по сути единственная операция: "вычислить значение в таких-то условиях". Поэтому структура по сути должна хранить: выбранную функцию и параметры к ней. При этом желательно, чтобы кастомизация не требовала изменений "ядерного" кода, то есть, грубо говоря, я мог бы сделать


и эта функция подхватилась бы системой и стала доступна для выбора.

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

П-ЛПодобные системы задания дат есть в развитых финансовых системах - именно так формулируется в договорах на совершение сделок. Задаются правило переноса дней в случае попадания на выходной, праздники по календараям каких стран должны учитываться и т.п. Реализовать это добросовестно - нужно много таблиц и средств управления/настройкой этого хозяйства. Как промежуточный вариант - по более простым условиям генерируются плановые даты, которые при необходимости чуть корректируются и используются в дальнейшем.
Ход мыслей понятен. Я сначала примерно так и хотел сделать: 1 ) каждый день (точнее ночь) формируется список задач, которые с учётом пересчёта сроков выпадают на ближайшую перспективу 2) юзер соглашается или меняет срок. Проблемы следующие: заданий может быть много (здесь никуда не уйти); как точно определить, что о задаче нужно напомнить; но самая главная проблема остаётся: как уйти от "лингвистического" задания дат, т.е. "последний день месяца", "каждая вторая суббота" и т.п.
Я всё-же рассчитываю на некое универсальное решение по заданию и хранению в базе сроков с разными "лингвистическими" условиями или параметрами.

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

Кот Матроскинсуществует 2, ровно 2 календаря - т.н. "полный" и т.н. "табель календарь". Если появляется нечто третье - систему надо переписывать.
Если в системе хранится "полный" календарь, то разработчиков системы надо самих переписывать, если конечно они не являются противниками Григореанского календаря (может я пропустил, когда его отменят? и выйдет релиз соответствующих серверов баз данных?) и имеют собственные представления о времяисчислении.