Выкладка схемы базы данных для приложения календаря

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

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

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

Обновление 1

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

Ответ 1

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

В конце концов я придумал полу-хак-иш-решение. Я создал столбец event_type. В этой колонке у меня были либо: "ежедневно", "еженедельно", "ежемесячно" или "ежегодно". У меня также были столбцы start_date и end_date. Все остальное было обработано в фактическом бэкэнд-коде.

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

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

Ответ 2

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

Создайте таблицу, содержащую все события

EventID (primary key)
Description
StartDate
PeriodType - days, weeks, months, years
PeriodFreq - # of days, weeks, etc between events
EndDate
... other attributes that can be modified

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

EventID (key)
InstanceID (key)
InstanceDate - the modified date of the exception 
IsCancelled - a flag to skip this date when traversing the series
... other attributes that can be modified

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

Ответ 3

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

API календаря - это REST API, к которому можно получить доступ через явные HTTP-вызовы; API предоставляет большинство функций, доступных в веб-интерфейсе Google Calendar, поэтому ваше приложение для календаря может использовать столько функций, сколько Google Calendar (много функциональности!!!).

Вашему приложению необходимо реализовать OAuth 2.0 для API Google, что упростится с помощью единого входа, например Auth0, чтобы предоставить соответствующие токены доступа. Затем ваше приложение календаря может использовать эти маркеры в сочетании с API-интерфейсом календаря для обеспечения беспрепятственного хранения и поиска событий календаря в формате JSON.

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

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

Ответ 4

Удерживайте повторяющийся элемент в таблице событий как обычно, но помечен как повторяющийся с соответствующими датами начала и окончания.

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

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

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

Ответ 5

Не могли бы вы объединить два мира с таблицей "кеш", в которой вы предварительно вычислили следующие события событий в течение X дней?

Итак, три таблицы:

recurring_event_specs
one_time_events
cached_recurring_events

Для любой части календаря в течение X дней сегодняшнего дня ваш запрос будет UNION one_time_events и cached_recurring_events.

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

Таблица cached_recurring_events должна обновляться всякий раз, когда пользователь добавляет новое повторяющееся событие - и, возможно, один раз в день в автономном режиме с помощью задания cron-job/sched-task. Но только в дни, когда не было создано нового повторяющегося события.

Ответ 6

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

Ответ 7

Не могли ли вы сохранить события в день с началом и временем окончания? Он будет генерировать много данных для событий, которые происходят каждый день (может быть, для них нет реляционных отношений), но это упростит запросы, и можно будет делать исключения (например, место события сгорело, или сотрудники поражают). Чтобы генерировать дни для события, я предложил бы реализовать это в интерфейсе, полученном на некотором ICal-ish шаблоне.