Разработка календарной системы наподобие Google Calendar

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

Вы можете попытаться генерировать будущие события по требованию и заполнять их только тогда, когда это необходимо для их отображения или отправки уведомления о них. Однако, если вы все равно собираетесь создавать код поколения "on-demand", почему бы не использовать его постоянно? Вместо извлечения из таблицы событий и последующего использования генерации событий по требованию для заполнения всех новых событий, которые еще не были добавлены в таблицу, просто используйте исключительно генерацию событий по требованию. Конечный результат будет таким же. С помощью этой схемы вам нужно только сохранить даты начала и окончания и частоту событий.

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

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

Я решаю именно эту проблему, и я полностью разделил iCalendar ( rfc 2445 ) до чтения этого потока, поэтому я понятия не имею, насколько хорошо это будет или не будет интегрироваться с этим. Во всяком случае дизайн который я придумал до сих пор выглядит примерно так:

• Вы не можете хранить все экземпляры повторяющегося события, по крайней мере до их возникновения, поэтому у меня просто есть одна таблица, в которой хранится первый экземпляр события в виде фактической даты, необязательного срока действия и nullable repeat_unit и repeat_increment поля для описания повторения. Для единичных экземпляров полями репитирования являются null, в противном случае единицы измерения будут 'day', 'week', 'month', 'year', а инкремент-это просто кратность единиц, добавляемых к дате начала следующего события.
• Хранение прошлых событий кажется выгодным только в том случае, если вам нужно установить отношения с другими сущностями в вашей модели, и даже тогда не обязательно иметь явную таблицу "event instance" в каждом случае. Если другие сущности уже имеют данные даты / времени "instance", то внешний ключ к событию (или таблица соединения для many-to-many), скорее всего, будет достаточным.
• Чтобы сделать "изменить этот экземпляр"/" изменить все будущие экземпляры", я планировал просто дублировать события и заканчивать устаревшие. Таким образом, чтобы изменить один экземпляр, вы бы истек старый в его последнем появлении, сделали копию для нового, уникального появления с изменениями и без какого-либо повторения, и еще одну копию оригинала в следующем появлении, которое повторяется в будущем. Изменение всех будущих экземпляров аналогично, вы просто истечете срок действия оригинала и сделаете новую копию с изменениями и деталями повторения.

Две проблемы, которые я вижу с этим дизайном до сих пор::

1. Это затрудняет представление событий типа MWF. Это возможно,но заставляет пользователя создавать три отдельных события,которые повторяются еженедельно на M, W, F по отдельности, и любые изменения, которые они хотят внести, также должны быть сделаны на каждом из них отдельно. Такие события не особенно полезны в моем приложении, но они оставляют бородавку на модели, что делает ее менее универсальной, чем мне бы хотелось.
2. Копируя события для внесения изменений, вы нарушаете связь между ними, что может быть полезно в некоторых сценариях (или, возможно, это просто иногда будет проблематично.) Таблица событий теоретически может содержать поле идентификатора "copied_from" для отслеживания происхождения события, но я еще не до конца продумал, насколько полезным может быть что-то подобное. Во-первых, иерархические отношения родитель/потомок являются проблемой для запроса из SQL, поэтому преимущества должны быть довольно тяжелыми, чтобы перевесить затраты на запрос этих данных. Я полагаю, вы могли бы использовать вместо этого вложенный набор .

Наконец, я думаю, что можно вычислить события для заданного промежутка времени, используя straight SQL, но я не разработал точные детали, и я думаю, что запросы обычно оказываются слишком громоздкими, чтобы быть стоящими. Однако в качестве аргумента можно использовать следующее выражение для вычисления разницы в месяцах между данным месяцем и годом события:

(:month + (:year * 12)) - (MONTH(occursOn) + (YEAR(occursOn) * 12))

Основываясь на последнем примере, вы можете использовать MOD, чтобы определить, является ли разница в месяцах правильным кратным числом:

MOD(:month + (:year * 12)) - (MONTH(occursOn) + (YEAR(occursOn) * 12), repeatIncrement) = 0

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

Как уже говорилось, Не изобретайте велосипед , а просто улучшайте его.

Checkout VCalendar, это открытый исходный код, и поставляется в PHP, ASP и ASP.Net (C#)!

Также вы можете проверить Day Pilot , который предлагает календарь, написанный в Asp.Net 2.0. Они предлагают облегченную версию, которую вы можете проверить, и если она работает для вас, вы можете приобрести лицензию.

Обновление (9/30/09):

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

Я бы сказал, начать со стандарта ical. Если вы используете его в качестве своей модели, то вы сможете сделать все, что google calendar, outlook, mac ical (программа), и получить практически мгновенную интеграцию с ними.

Оттуда, время, чтобы скостить на вашем ajax и javascript, потому что вы не можете иметь яркий веб-интерфейс с перетаскиванием и несколькими календарями без тонны ajax и javascript.

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

Это позволяет вам говорить "this event appears every day" для ежедневного, "this event appears on the 2nd day of every week" для еженедельного, "this event appears on the 5th day of every month" для ежемесячного, "this event appears on the 215th day of every year" для годового, пока дата меньше даты истечения срока действия.

Даррен,

Именно так я разработал свою таблицу событий на самом деле, но когда я думаю об этом, скажем, у меня есть 100 тысяч пользователей, которые создают события, эта таблица будет поражена довольно сильно, особенно если я буду рассылать электронные письма, чтобы напомнить людям об их событиях (события могут быть также для определенного времени суток!), так что я мог бы опрашивать этот стол каждые 15 минут потенциально!

Вот почему я хотел создать другую таблицу, которая бы расширяла все события events/re-occuring, таким образом, я могу просто ударить по этой таблице и получить представление пользователей о событиях, не делая никаких сложных запросов и бизнес-логики, AND это также сделает опрос намного более эффективным.

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

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

ChanChan,

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

brute-force-ish но все же разумным способом было бы создать новую строку в вашей отдельной таблице событий для каждого экземпляра повторяющегося события, указывая не на событие, предшествующее ему в Серии , А на первое событие в серии. Это упрощает выбор и / или удаление всех элементов в определенной серии, так как вы можете выбрать на основе родительского идентификатора. Он также позволяет пользователям удалять отдельные элементы из серии, не затрагивая rest из них.

Этот запрос возвращает вам серию, которая начинается с элемента 3:

SELECT * FROM events WHERE id = 3 OR parentid = 3

Чтобы получить все элементы за этот месяц, предположив, что у вас есть дата начала и дата окончания в таблице событий, все, что вам нужно сделать, это:

SELECT * FROM events WHERE startdate >= '2008-08-01' AND enddate <= '2008-08-31'

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

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

Это не плохая идея, чтобы создать подчиненную таблицу, в зависимости от вариантов использования. Алгоритм вычисления точного времени возникновения событий . . . ЭМ, случись . . . может действительно быть довольно сложным. От его запуска никуда не денешься, но стоит подумать о кэшировании результатов.

@GateKiller

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

Однако когда вы это делаете, как далеко в будущем вы сохраняете события? Вы выбираете произвольную дату? Вы автоматически генерируете новые вхождения при первом просмотре пользователем будущего months/years?

Кроме того, как вы обрабатываете случай, когда пользователь хочет отредактировать всю серию. "У нас была встреча каждый вторник утром в 10:30, но мы собираемся начать встречаться в среду в 8"

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

Это имеет два преимущества:

1. Никаких сложных процедур для определения даты следующего события
2. Отдельные вхождения можно редактировать, не затрагивая rest

Надеюсь, это даст вам пищу для размышлений :)

Если кто-то делает Ruby, есть отличный библиотечный Коротышка, который делает такие вещи. Стоит проверить. http://runt.rubyforge.org/

неопределенный написал:

…this таблица будет поражена довольно трудно, особенно если я собираюсь быть отправка электронных писем, чтобы напомнить людям о их события (события могут быть для а также в определенное время суток!), так что я мог бы опрашивать этот стол каждые 15 минут потенциально!

Создайте таблицу для уведомлений. Опросите только его.

Обновляйте таблицу уведомлений при обновлении событий (повторяющихся или других).

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

Дерек Парк, Я буду создавать каждый экземпляр события в таблице, и эта таблица будет регенерироваться каждый месяц (поэтому любое событие, которое было установлено в reoccurr 'forever', будет регенерироваться за один месяц вперед с помощью службы windows или, возможно, на уровне сервера sql). Опрос будет проводиться не только каждые 15 минут, но и только для опросов, связанных с уведомлениями email. Когда кто-то хочет просмотреть свои события в течение месяца, я должен буду выбрать все их события, а также повторные события и выяснить, какие события отображать (поскольку повторное событие могло быть создано 6 месяцев назад, но относится к месяцу, который просматривает пользователь).

Зак, я не слишком озабочен тем, чтобы иметь идеально нормализованную базу данных, тот факт, что я думаю о создании вторичной таблицы, уже нарушает одно из правил, хе-хе. Мои основные таблицы базы данных следуют 'the rules', но я не возражаю против создания вторичных таблиц/столбцов в те моменты, когда это выгодно с точки зрения производительности.

Именно так я разработал свою таблицу событий на самом деле, но когда я думаю об этом, скажем, у меня есть 100 тысяч пользователей, которые создают события, эта таблица будет поражена довольно сильно, особенно если я буду рассылать электронные письма, чтобы напомнить людям об их событиях (события могут быть также для определенного времени суток!), так что я мог бы опрашивать этот стол каждые 15 минут потенциально!

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

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

Затем можно разделить информацию по нескольким базам данных для целей масштабирования. т. е. пользователи 1-10000 календарей существуют на сервере 1, 10001-20000 существуют на сервере 2 и т.д.

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

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

Повторные события должны иметь начальную дату и дату остановки (которая может быть Null для событий, продолжающихся каждые X дней "forever"), вам нужно будет решить, какую частоту вы хотите разрешить-каждые X дней, N-й день каждого месяца, каждый заданный день недели и т. д.

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

Если бы я собирался заняться этим (и я бы изо всех сил старался не изобретать это колесо), я бы искал библиотеки с открытым исходным кодом или, по крайней мере, проекты с открытым исходным кодом с календарями, которые вы можете посмотреть. Есть какие-нибудь рекомендации, ребята?

Стартовый комплект календаря Ra-Ajax содержит образец обработки события RenderDate, который может изменять даты конкретно. Хотя "recurring events"-это скорее алгоритмическая вещь, и здесь я сомневаюсь, что очень немногие календари вам сильно помогут...