Я бы просто создал запись для каждого повторения события на некотором горизонте.Однако это означает, что вам понадобится еще одна таблица, которую вы можете использовать для проецирования дат, если они сканируют дату вашего горизонта.То есть вам понадобится таблица событий, которая содержит одну запись для каждого повторения события (1 января, 8 января, 15 января, ... по декабрь) и таблицу с каждой записью, доступной для заполнения будущих лет (началодата: 1 января; повторение: 7; до: 2011), так что в начале 2012 года (или как только пользователь запросит просмотр месяца 2012+) вы сможете генерировать будущие события.
Этоимеет два больших недостатка:
- В вашей базе данных есть данные за полный год.Однако, если добавление данных за полный год ухудшит вашу производительность, ваша система, вероятно, будет недостаточно мощной.(Кажется, требуется, чтобы приложение календаря могло обрабатывать даты на многие годы)
- В конце горизонта событий вам нужно сгенерировать будущие даты для повторяющихся событий.
Преимущества (IMO), которые перевешивают недостатки:
- Упрощенная математика при отображении календаря.Используя метод Тима, описанный выше, если пользователь загружает 18 декабря 2011 года, как вы будете рассчитывать, какие повторяющиеся события следует размещать в этот день?Вы будете вынуждены циклически проходить КАЖДЫЕ повторяющиеся события каждый раз, когда отображаете дату.Компромиссом является недостаток № 1, который, я думаю, является лучшим решением, когда необходимо повторить эти вычисления.
- Вы можете редактировать определенные экземпляры события.Используя метод Тима, если встреча произошла в праздничный день и пользователь изменил ее на предыдущий день, как бы вы это сделали?Используя метод «одна запись на событие», описанный здесь, вы можете просто изменить эту запись для события, легко перемещая отдельные события в календаре.