Saboteur, каждая дата это отдельная строка, просто проверяя каждую секунду например 1м записей это ужасная затрата ресурсов, раз в 5м тоже такое себе, нужно тогда учитывать что дата уже могла на 5м быть пройдена. Я думал может есть чет на подобие вебхуков, то есть когда остался час до даты отправлялся запрос мне в основной скрипт который обрабатывал его и все, то есть чтобы нужная дата сама отправлялась. Тоесть мой скрипт просто ожидает например запрос который прийдет от бд и тогда его исполняет, хотя возможно это так и устроенно что есть просто скрипт в постгрескл который постоянно проверяет дату, но я бы хотел какой-то триггер чтоли. Надеюсь я понятно высказался
Maxwell012, Если это поможет, то я думаю сохранят в планировщик только одну переменную что является индентификатором на определнную строку в бд и когда ее время исполнение доходит то уже через айди достоется нужная информация с бд и отправляется оповещение клиенту. Я имею виду что я не буду хранить много информации для запуска одной задачи, поэтому миллион задач в планировщике даже если в оперативе это не так уж много, но мне нужно рассчитывать на то что вес задач может привышать обьем оперативной памяти поэтому лучше сохранять их на диск плюс это защитит меня от перезагрузки сервера и т.д.
извиняюсь за неточную информацию, было тяжело сформулировать. У меня есть бот на python + aiogram, пользователи регистрируюца на определнное событие дата которого может быть хоть через 3 месяца (может и больше, но пока что я взял эту орентировачную длину), так вот мне нужно чтобы когда до назначиной даты оставался день отправить сообщение предупреждающее + когда останиться 3 часа еще одно оповещение. Я просто не сильно вижу смысл помещать в планировщик задачи которые могут быть использованы через 3 месяца. Количество запросов я не могу точно сказать, но я орентируюсь на то что запланнированных задач может быть миллион. Я не совсем понимаю где планировщики хранят задачи, они хранят в оперативной памяти или сохраняют их на диск, просто если они сохраняются на диск то впринципе планировщики идеально подходят потому что мне не нужны задачи в оперативе которые исполняться только через 3 месяца
ваш код не проверял но думаю он рабочий, я уже разобрался с этим вопросом и у меня похожий код как у вас). Мне только не нравиться то что для создания бд нужно как минимум один еще метод вызывать чтобы создать пул, но это не проблема просто моя привередливость
Сергей Горностаев, вы имете виду если у человека несколько интервалов времени в дне то делать под каждый интервал строку. Еще тогда вопрос, забронированное время лучше вынести в отдельную таблицу где будут все брони?
Slava Rozhnev, я не заметил что вы исправили ответ, выглядит круто, но проблема в том что я не могу добавить четкое время, это может быть например 10 - 12, 16 - 18, для этих отрезков я создаю 2 строчки но что делать если заняли пол часа только у первого времени, возможно вы подумали что тогда можно создавать много отрывков по пол часа, но проблема в том что я не знаю сколько времени будет выделенно мастером для какой-то задачи/работы, поэтому это перестает работать для меня
Сергей Горностаев, Я пытаюсь сделать правильно, но возникли пару вопросов, хотел бы пропросить немного сконтолировать процесс. Я создал таблицу:
CREATE TABLE specialist_availability (
id BIGINT,
date DATE,
time tsrange[]
);
я использовал tsrange[] для того чтобы можно было добавлять отрывки вермени или вычеркивать время тем самым создавая пробелы, но проблема в том что gist не предусмотрен для tsrange[], если смысл создавать свой операторный класс для того чтобы создать gist?
Сергей Горностаев, много строк я имел виду, так как мне нужно хранить пол года хотя бы наперед для специалиста чтобы люди могли записываться, а то есть 150 дней например, ну а это уже 150 строк
alexalexes, на счет архивации слотов которые истекли я не подумал, я их действительно могу перенести в просто список так как с этими данными редко работают. А на счет индексов не сильно понял, мне нужно каждый рабочий день человека добавлять
читал про этот тип данных, не сильно он мне понравился, но как я вижу прийдется мне им воспользоваться. Но все равно получиться почти такая же ситуация как 1 ответ выше, получиться сильно много столбцов + в идеале вынести дату в идеальную колонку чтобы быстрее происходил поиск так как tsrange конвертируется в строку как я понимаю а назат в дату конвертировать и потом проверять какой это день это будет долго. Проблема в том что мне надо постоянно обращаться в бд и доставать свободные часы человека, но если хранить в таблицы все дни всех людей то это получиться бесконечная таблица
вы предлагаете хранить каждый день отдельно, но это только для одного участника например на год будет 365 полей, а людей например возьмем 1000, это уже 365к полей
