Оптимальный дизайн для базы данных с повторяющимся событием

Я бы просто создал запись для каждого повторения события, на каком-то горизонте. Однако это означает, что вам понадобится другая таблица, которую вы можете использовать для проецирования дат, если они сканируют вашу дату горизонта. То есть вам понадобится таблица событий, которая содержит одну запись для каждого события повторного события (1 января, 8 января, 15 января, … до декабря) и таблицу с каждой записью, доступной для будущих лет (начало дата: 1 января, повторение: 7; через: 2011), так что в начале 2012 года (или как только пользователь запросит представление о месяце 2012+) вы сможете генерировать будущие события.

Это имеет два больших недостатка:

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

Преимущества (ИМО), которые перевешивают недостатки:

1. Легкая математика при отображении календаря. Используя метод Тима, выше, если пользователь загружает 18 декабря 2011 года, как вы собираетесь рассчитать, какие повторяющиеся события должны быть размещены в этот день? Вы будете вынуждены проходить через КАЖДОЕ повторное событие каждый раз, когда вы показываете дату. Компромисс – это недостаток №1, который, я думаю, является лучшим решением, позволяющим повторить эти вычисления.
2. Вы можете редактировать конкретные экземпляры события. Используя метод Тима, если встреча произошла в праздник, и пользователь изменил ее на предыдущий день, как бы вы это сделали? Используя описанный здесь метод one-entry-per-event, вы можете просто изменить эту запись для события, легко перемещая отдельные события в календаре.

У вас может быть столбец в таблице EVENT для RECURRENCE_STATUS, который отслеживает 4 значения, не повторяется, еженедельно, ежемесячно, ежегодно. Запрос событий дня будет объединением тех, которые установлены в этот день и которые не повторяются с набором тех, которые повторяются и чья первоначальная разница в дате с сегодняшнего дня является модулем 0 для недели, месяца и год различий. Расчеты по дате-математике немного более тонкие, чем это (из-за различного количества дней в месяце), но структура должна быть достаточной.