Разработка Системы календаря как [закрытый] Google Calendar

Если кто-либо делает Ruby существует большая библиотека Runt, которая делает такого рода вещь. Стоящий проверки. http://runt.rubyforge.org/

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

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

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

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

Календарный стартовый набор Ajax Ра показывает образец обработки события RenderDate, которое может изменить даты конкретно. Хотя "повторяющиеся события" являются большим количеством алгоритмической вещи, и здесь я сомневаюсь, что очень немного календарей помогут Вам очень...

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

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

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

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

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

Derek Park, я создал бы каждый экземпляр события в таблице, и эта таблица будет повторно создаваться каждый месяц (так любое событие, которое было установлено повторяться, 'навсегда' будет повторно создан один месяц заранее с помощью сервиса окон или возможно на уровне SQL-сервера). Опрос будет не только делаться каждые 15 минут, который мог бы только быть для опросов, связанных с уведомлениями по электронной почте. Когда кто-то захочет просмотреть их события в течение месяца, у меня будут к fetech все их события, и повторяющиеся события и фигура, которую события отобразиться (так как повторяющееся событие, возможно, было создано 6 месяцев назад, но касается месяца пользователь, просматривают).

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

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

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

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

Обновите таблицу уведомления, когда события (возвращение или иначе) будут обновлены.

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

@GateKiller

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

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

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

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

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

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

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

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

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

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

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

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

Надежда это дает Вам некоторую пищу для размышления :)

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

Этот запрос получает Вас ряд, который запускается на элементе 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 на Ваших событиях, позволяя Вам свободу слоняться без дела с одиночными соревнованиями при тихом сохранении контроля над рядом.

Darren,

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

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

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

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

ChanChan,

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

Я сказал бы, запускаются со стандарта iCal. Если Вы будете использовать его в качестве своей модели, то Вы сможете сделать все, что Google Календарь, перспектива, iCal Mac (программа), и получают фактически мгновенную интеграцию с ними.

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

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

Это позволяет Вам говорить, что "это событие появляется каждый день" для ежедневной газеты, "это событие появляется в 2-й день каждой недели" для еженедельника, "это событие появляется в 5-й день каждого месяца" для ежемесячного журнала, "это событие появляется в 215-й день каждого года" для ежегодно, пока дата является меньше, чем дата истечения срока.

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

Контроль VCalendar, это - открытый исходный код и прибывает в PHP, ASP и ASP.NET (C#)!

Также Вы могли проверить Дневного Пилота, который предлагает календарь, записанный у Asp. Сетевые 2.0. Они предлагают облегченную версию, которую Вы могли проверить, и если она работает на Вас, Вы могли бы купить лицензию.

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

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

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

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

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

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

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

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

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

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

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