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

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

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

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


person kemiller2002    schedule 03.01.2009    source источник


Ответы (2)


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

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

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

person Radu094    schedule 03.01.2009

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

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

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

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

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

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

person Jonathan Leffler    schedule 03.01.2009