Структура данных календаря времени

Question

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

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

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

Answer 1

Я нашел эту книгу вдохновляющей и обязательной к прочтению при работе с любыми базами данных, связанными с тайм-менеджментом/ограничениями:

Разработка приложений баз данных, ориентированных на время, на SQL

(Добавил редактор:тот книга доступен онлайн через Ричард Снодграссдомашняя страница.Это хорошая книга.)

Answer 2

@Radu094 указал вам на хороший источник информации, но обработать его будет сложно.

На ужасно прагматичном уровне вы рассматривали возможность записи встреч и доступной информации в одну таблицу, а не в две таблицы?Для каждого дня разделите время на «никогда недоступно» (до открытия офиса, после закрытия офиса — если такое произойдет), «доступно — можно выделить» и «недоступно».Эти (два или) три класса бронирований будут записываться в последовательные интервалы (с указанием времени начала и окончания каждого интервала в одной записи).

Для каждого номера и каждой даты необходимо создать набор «неиспользуемых» бронирований (в зависимости от того, выбираете ли вы «никогда не доступно», набор может состоять из одной «доступной» записи или может включать раннюю смену и записи поздней смены, которые никогда не доступны).

Затем вам нужно выяснить, какие вопросы вы задаете.Например:

• Могу ли я забронировать номер X в день Y между Т1 и Т2?
• Есть ли свободные места в день Y между Т1 и Т2?
• В какое время дня Y комната X еще доступна?
• В какое время в День Y будет доступен зал с аудиовизуальными возможностями и вместимостью 12 человек?
• Кто забронировал номер X утром дня Y?

Это лишь малая часть возможностей.Но при некоторой осторожности и внимании к деталям запросы становятся управляемыми.Проверить ограничения в СУБД будет сложнее.То есть, если время [T1..T2) забронировано, никто другой не забронирует [T1+00:01..T2-00:01) или любой другой перекрывающийся период.Видеть Интервальная алгебра Аллена в Википедии и других местах (включая этот на uci.edu).