Вопрос дизайна: Как бы вы создали повторяющуюся систему событий?


44

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

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

Один дизайн за ответ пожалуйста. Я привык к Ruby/Rails, но использую то, что вы хотите выразить.

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

Примечание: был already asked/answered here. Но я надеялся получить некоторые более практические детали, как описано ниже:

  • Если бы это было необходимо, чтобы иметь возможность комментировать или иначе добавить данные только одного экземпляра повторяющегося события , как это будет работать?
  • Как будут происходить изменения и удаления событий?
  • Как вы рассчитываете, когда происходят будущие события?
+1

Мне нравится этот вопрос, но я подозреваю, что он будет закрыт. 28 окт. 142014-10-28 20:23:43

  0

@ joe-van-dyk Эй, у меня такая же проблема, можете ли вы добавить свои рекомендации и ссылку на свое решение git в части ответа !? Я считаю, что вы решили эту проблему. Мне интересна модель данных в целом. Спасибо 16 май. 172017-05-16 18:42:48

0

При сохранении события я бы сохранить график в магазин (давайте назовем его «Расписание», и я бы вычислить, когда событие было стрелять в следующий раз, и кроме того, что, как хорошо, например, в «События». Тогда я хотел бы посмотреть в «События» и выяснить, когда следующее событие должно было произойти, и идти не спать до тех пор.

когда приложение «просыпается» это вычислить бы при событие должно быть выполнено снова, затем сохраните его в поле «События», а затем выполните событие.

Повторите.

Если во время сна создано событие, сон прерывается и пересчитывается.

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

Что-то вроде этого было бы гибким и не требовало бы ненужных циклов процессора.

  0

Не могли бы вы посмотреть в будущее и посмотреть, когда будут предстоящие события? 23 сен. 082008-09-23 21:03:25


2

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


0

Off верхней части моей головы (после пересмотра пары вещей при вводе/мышления):

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

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

Каждый раз, когда приложение запускается, оно проверяет все события, сравнивая (today/now + recurrenceResolution) с (recentRunTime + runInterval) и, если они совпадают, запускайте событие.


2

@ Joe Van Dyk спросил: «Не могли бы вы посмотреть в будущее и посмотреть, когда будут предстоящие события?»

Если вы хотите см/дисплей следующие п вхождений события они должны либо а) рассчитывается заранее и хранить где-то или б) быть рассчитаны на лету и отображается. Это было бы одинаково для любых вечерних рамок.

Недостаток a) заключается в том, что вы должны наложить на него предел, а после этого вы должны использовать b). Легче просто использовать б) для начала.

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

  0

Или смешайте два. Вычислите по требованию (b), затем сохраните результаты для последующей ссылки (a). 24 сен. 082008-09-24 06:34:28


0

Когда я написал приложение для календаря для себя mumble лет назад, я в основном просто украл механизм планирования из cron и использовал его для повторяющихся событий. например, что-то, что происходит во вторую субботу каждого месяца, кроме января, будет включать инструкцию «repeat = * 2-12 8-14 6» (каждый год, месяцы 2-12, вторая неделя проходит с 8-го по 14-й, и 6 в субботу, потому что я использовал нумерацию на основе 0 для дней недели).

Хотя это довольно легко определить, происходит ли событие в любую заданную дату, оно не способно обрабатывать повторение «каждый N дней» и также не столь интуитивно понятное для пользователей, которые не являются совместимыми с Linux.

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

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


0

Если у вас есть простое повторное событие, такое как ежедневное, еженедельное или пару дней в неделю, что случилось с использованием buildt в scheduler/cron/at functionallity? Создание исполняемого/консольного приложения и настройка, когда его запускать? Нет сложного календаря, события или управления временем.

:)

// Ш

+1

не работает для веб-приложения 06 окт. 082008-10-06 01:34:53


9

Я начал путем реализации некоторой временной экспрессии, как outlined by Martin Fowler. Это позаботится о том, чтобы выяснить, когда запланированный элемент должен произойти. Это очень элегантный способ сделать это. То, что я закончил, было всего лишь результатом того, что в статье.

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

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

Что касается экземпляров заданий, то существует «служба», которая генерирует задачи для N дней. Поскольку это интеграция с существующей системой, и все экземпляры необходимы, это имеет смысл. Однако такой API можно легко использовать для прогнозирования повторений без сохранения всех экземпляров.