Структура данных календаря времени - PullRequest
4 голосов
/ 03 января 2009

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

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

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

Ответы [ 2 ]

6 голосов
/ 03 января 2009

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

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

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

5 голосов
/ 03 января 2009

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

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...