Как разместить календарь в Postgresql?

Question

[Maxwell012]

У меня есть специалисты, мне нужно для каждого хранить доступные часы каждого дня, любой промижуток в дне могут забранировать и мне нужно учитывать это и удалять этот промежуток времени с доступного времени.
Пока что у меня одна очень странная идея, это просто сделать словарь который будет выглядить как-то так:

{
    'year': {
                  'august': {
                                    '1': ['8:00', '8:30', '9:00', '10:00', ...], 
                                     ......}
                  .......}
}

но это медленно все будет + я почти уверен что это не правильное решение, прошу подсказать как правильно поступить в этой ситуации

Comments

[Петр]

8:00 это 480 минут. Храните просто в виде офсета от начала дня.

[Maxwell012]

Петр, как тогда понимать какой участок времени был забронирован?

Answer 1

[Сергей Горностаев]

Для расписаний подходит тип tsrange с GiST-индексом.

Comments

[Maxwell012]

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

[Сергей Горностаев]

Maxwell012, зачем много столбцов? Колонка с идентификатром специалиста и колонка с tsrange доступного времени. Если в день один период доступности, то на описание недели делаешь семь строк и всё. И нет, tsrange в строку не конвертируется, а поиск по ним очень быстрый при наличии индекса, причём можно и с достаточно сложными условиями типа "найти самые ранние незанятые полчаса в расписании такого-то специалиста со следующего вторника по четверг".

[Maxwell012]

Сергей Горностаев, много строк я имел виду, так как мне нужно хранить пол года хотя бы наперед для специалиста чтобы люди могли записываться, а то есть 150 дней например, ну а это уже 150 строк

[Сергей Горностаев]

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

[Maxwell012]

Сергей Горностаев, ну тут смотря с чем сравнивать, но вы правы), это не так уж и много

[Сергей Горностаев]

Maxwell012, если все сделать правильно, операции у вас не будут выполняться дольше нескольких миллисекунд.

[Maxwell012]

Сергей Горностаев, Я пытаюсь сделать правильно, но возникли пару вопросов, хотел бы пропросить немного сконтолировать процесс. Я создал таблицу:

CREATE TABLE specialist_availability (
    id BIGINT,
    date DATE,
    time tsrange[]
);

я использовал tsrange[] для того чтобы можно было добавлять отрывки вермени или вычеркивать время тем самым создавая пробелы, но проблема в том что gist не предусмотрен для tsrange[], если смысл создавать свой операторный класс для того чтобы создать gist?

[Сергей Горностаев]

Maxwell012, зачем вам массив? Массивы - это почти всегда нарушение реляционных принципов. Храните данные в отдельных строках.

[Maxwell012]

Сергей Горностаев, вы имете виду если у человека несколько интервалов времени в дне то делать под каждый интервал строку. Еще тогда вопрос, забронированное время лучше вынести в отдельную таблицу где будут все брони?

[Сергей Горностаев]

Maxwell012, да, по строке на каждый интервал. И да, я был сделал таблицу с расписанием и таблицу с бронированиями.

[Maxwell012]

Сергей Горностаев, спасибо за советы)

Answer 2

[Slava Rozhnev]

Самый простой вариант таблица timeslots заполняется заранее занятые слоты отмечаются

create table timeslots (
    staff_id int,
    date date,
    time_from time,
    time_to time,
    free boolean default true
);

https://sqlize.online/sql/psql15/a8eeaa5579150c5f2...

Воспользовавшись советом Сергей Горностаев можно сделать так:

CREATE EXTENSION btree_gist;

create table timeslots (
    staff_id int,
    slot_time tsrange,
    free boolean default true,
    EXCLUDE USING GIST (staff_id WITH =, slot_time WITH &&)
);

https://sqlize.online/sql/psql15/b54b8d9ac47201ff2...

Comments

[Maxwell012]

вы предлагаете хранить каждый день отдельно, но это только для одного участника например на год будет 365 полей, а людей например возьмем 1000, это уже 365к полей

[alexalexes]

Maxwell012, вообще, не объемистая выборка, при правильно созданных индексах под нужные условия выборки запросов.
Также можно удалять свободные слоты, если время их истекло, и проводить фрагментацию и дефрагментацию рядом стоящих записей по времени с целью сокращения слотов.

[Maxwell012]

alexalexes, на счет архивации слотов которые истекли я не подумал, я их действительно могу перенести в просто список так как с этими данными редко работают. А на счет индексов не сильно понял, мне нужно каждый рабочий день человека добавлять

[Slava Rozhnev]

Maxwell012, Да, именно так. Для каждого человека вперед на неделю/месяц/год сколько у вас там горизонт планирования добавляем слоты в соответствии с его расписанием. Индексы на таблицу по staff_id + date, Можно еще GIST индекс чтоб защититься от коллизий

[Slava Rozhnev]

Maxwell012,

365к полей

я думаю не полей а строк и 365к строк это не много

[Maxwell012]

Slava Rozhnev, я не заметил что вы исправили ответ, выглядит круто, но проблема в том что я не могу добавить четкое время, это может быть например 10 - 12, 16 - 18, для этих отрезков я создаю 2 строчки но что делать если заняли пол часа только у первого времени, возможно вы подумали что тогда можно создавать много отрывков по пол часа, но проблема в том что я не знаю сколько времени будет выделенно мастером для какой-то задачи/работы, поэтому это перестает работать для меня

[Maxwell012]

Maxwell012, возможно нужно создать отдельную таблицу в которой я буду хранить брони, но это уже начинает казаться мне не рациональным