Комментарии 12
Я писал маленький проектик поиграться с kotlin, который выкачивал календарь из открытых данных в csv, перегонял в json в нужном мне формате и сохранял просто как файл. Результат в кэш, а уже из кэша можно быстро доставать и делать нужные вычисления. Например узнать сколько рабочих дней между датами. Можно вызывать обновление, чтобы получить новую версию календаря с открытых данных. До 2020 года это можно было бы делать раз в год автоматически. Когда я в 2018 писал этот проектик, то на открытых данных уже был календарь до 2025 года.
Вот оно — github.com/jmorozov/productive-kalendar
И телеграм-бот к нему — github.com/jmorozov/productive-kalendar-telegram-bot
Вот товарищ делал — github.com/d10xa/holidays-calendar. Производственный календарь в json, который является результатам парсинга super-job и consultant.ru. 2 сайта — это для проверки, один может врать :)
А вот есть ещё апишка — isdayoff.ru/extapi
Ожидал увидеть для заполнения получение данных о праздничных дня вызовом сервиса, а оказалось как у многих — заполнение руками.
Кстати, pl/pgsql-код для заполнения можно одним sql-запросом заменить, работать будет быстрее.
Было бы интереснее увидеть, как решаются типичные задачи по календарю: рассчет промежутка времени без учета праздников/выходных/праздников и выходных, планирование и т. п.
Результирующий календарь получался объединением этих 2х таблиц.
А зачем явно создавать уникальный индекс по полю, которое является первичным ключом? Смотрю в Ваш план выполнения запроса, там используется индекс созданный автоматически для ограничения первичного ключа
Спасибо за замечание. Дело в том, что в нашей системе все таблицы создаются по предварительному описанию(метаданные в структуре Сущность-Атрибут-Значение) и имеют суррогатный первичный ключ. В примере я убрал лишние, не имеющие отношения к календарю поля. В реальной системе — это поле не первичный ключ, но уникальный индекс имеет
Это решение «в лоб». Хранить нужно только исключения от стандартного поведения по номеру дня недели, как в одну (рабочий -> выходной), так и в другую (выходной -> рабочий) сторону. Вместо тысяч записей, которые к тому же трудно модерировать, за 10 лет будет всего несколько десятков. Выборка идёт моментально через TVF, генератор строк и left join с исключениями. Доберусь до рабочего компа — пришлю пример кода
Интересное решение. Мне кажется вполне тянет даже на статью на хабр
Самое забавное, что исходные данные я тяну как раз из такой системы, в которой перечислены абсолютно все даты за время операционной деятельности и на 10 лет в будущее ;). В краткую же форму уже в БД своей системы конвертирую на лету.
С календарями вообще бывают интересные моменты — например при заключении договора между контрагентами в разных странах его дата должна быть рабочим днём в обеих странах. А, если например, инвойс выставлен одной из сторон другой стороне — то достаточно, чтобы дата инвойса была рабочим днём только выставляющей стороны. Это все довольно тривиально, но вокруг календаря построены функции, которые позволяют это делать.
Похоже, действительно можно сделать на эту тему пост ;)
а вообще есть xmlcalendar.ru откуда можно импортировать всё в бд без всякого ручного труда. В пятерке результатов гугла по запросу «календарь выходных дней импорт» и другим подобным запросам
А как потом с этим дырявым календарем работать?
Я работал с системой, в которой была банальная табличка дата/выходной по версии РФ/выходной по версии фирмы
Для бд справочник на несколько тысяч строк обычное дело.
Тривиально джойнится, не усложняя запросы. Сама по себе табличка может быть основой запроса, к ней уже left outer join цепляешь нужные данные за период
Производственный календарь своими руками в Postgresql