Приложение для планирования ресурсов

Я пытаюсь реализовать приложение, которое координирует работу нескольких пользователей, планирующих использование эксклюзивных ресурсов. Данные расписания должны поддерживать строгую согласованность в сети с одним главным узлом. Запланированные ресурсы могут быть чем угодно, от конференц-зала до работника на рабочем месте.

Мы предполагаем, что конференц-зал не может быть запланирован для двух совещаний одновременно, а работник не может находиться на двух рабочих местах одновременно. Бизнес-логика приложения не должна позволять пользователю «перезаказывать» ресурс.

Чего я не могу понять, так это того, как представить данные, чтобы, если два или более пользователей работали по расписанию одновременно и возникали конфликты, одно из обновлений прервалось.

Единственное решение, которое я видел до сих пор, — это отслеживать временные интервалы для каждого исключающего ресурса. Таким образом, если конференц-зал используется с 5-минутными интервалами, и он был запланирован на 9–9:30, то все соответствующие 5-минутные временные интервалы для 9–9:30 вернут TRUE, а незапланированные интервалы вернут FALSE или NULL. . Затем транзакция БД извлекает объект конференц-зала из хранилища, проверяет все временные интервалы и прерывается, если обновление конфликтует с существующими временными интервалами.

Тем не менее, похоже, что он станет очень большим, очень быстрым. Может быть, это сборщик мусора? Кроме того, одной из целей дизайна является поддержка переменной степени детализации, поэтому некоторые объекты будут планироваться ежеминутно, в то время как другие могут выполняться ежедневно, и этот дизайн данных не очень хорошо поддерживает это.

В настоящее время я пытаюсь реализовать это в Google App Engine с помощью Python, но мне было бы очень интересно увидеть некоторые более общие решения этой проблемы. Все, что я придумал с помощью Google, — это планирование повторяющихся задач или алгоритмов, которые выполняют однократные операции для автоматического построения оптимизированных расписаний.


person Kris Walker    schedule 08.10.2009    source источник
comment
Другое возможное решение — хранить блокировку ресурсов в хранилище данных. а затем потребовать от клиентов асинхронного получения блокировки перед представлением расписания пользователю в доступной для записи форме. Пока клиент не получит блокировку, расписание доступно только для чтения. Это эффективно сериализует операции и позволяет перенести бизнес-логику на клиент, но тогда проблема будет заключаться в определении верхних границ допустимой конкуренции за ресурсы.   -  person Kris Walker    schedule 09.10.2009


Ответы (2)


Вы захотите отслеживать только время начала и окончания для каждого исключающего ресурса. Хранение данных в вашей проблеме на самом деле является легкой частью - более сложной частью является создание запросов для поиска конфликтов во временных интервалах.

Если моя логика верна после 21 часа бодрствования, следующий псевдокод должен проверять наличие конфликтов встреч.

# Set up your proposed meeting
proposed.start = <thursday, 1pm>
proposed.end   = <thursday, 2pm>

# Look for meetings that intersect with or straddle proposed meeting
conflicts = <SELECT * FROM meeting WHERE
             meeting.start BETWEEN proposed.start AND proposed.end OR
             meeting.end   BETWEEN proposed.start AND proposed.end OR
             meeting.start <= proposed.start AND meeting.end >= proposed.end>


if conflicts.length > 0:
   # We have a conflict!
person Triptych    schedule 08.10.2009
comment
к сожалению, движок приложения не поддерживает предложенный вами запрос. Самая сложная часть заключается в том, что он позволяет фильтровать неравенство только по одному свойству. Кроме того, я не думаю, что он еще разрешает запросы OR. Вы можете обойти это (в основном), разбив запрос на 3 части: встреча.начало МЕЖДУ предложенным.началом И предложенным.концом и собрание.конец МЕЖДУ предложенным.началом И предложенным.концом оба действительны как есть. Но последнее предложение нужно будет изменить, чтобы не использовать 2 фильтра неравенства. code.google.com/appengine/docs/java/datastore/ - person Peter Recore; 09.10.2009
comment
Чтобы не показаться слишком придирчивым, я хочу добавить, что общая идея прекрасно решает проблему без накладных расходов на хранение данных для каждого возможного слота для каждого возможного ресурса. - person Peter Recore; 09.10.2009
comment
Этот запрос выглядит правильно, но, как сказал Питер, для использования хранилища данных App Engine потребуется некоторая работа. Это должно быть возможно, но мне нужно изучить это. - person Kris Walker; 09.10.2009

Для автоматической оптимизации расписания школы или университета (или даже других задач) взгляните на следующие инструменты Java:

TimeFinder, UniTime или Drools Solver

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

Во-первых, я бы разрешил только расписаниям доступ/изменение данных расписания.

Во-вторых, я бы создал независимое решение для каждого расписания, а затем оптимизировал бы это решение с помощью предложенных выше инструментов. Затем решения можно сохранить в базе данных, и планировщик может использовать их для дальнейшей оптимизации расписания или для сравнения с другими решениями.

person Karussell    schedule 10.01.2010