Просто бих създал запис за всяко повторение на събитието, до някакъв хоризонт. Това обаче означава, че ще ви е необходима друга таблица, която можете да използвате, за да проектирате датите, ако сканират след датата на хоризонта ви. Т.е., ще ви трябва таблица със събития, която съдържа един запис за всяко възникване на повтарящо се събитие (1 януари, 8 януари, 15 януари, ... до декември) и таблица с всеки запис, наличен за зареждане на бъдещи години (начало дата:1 януари; повторение:7; до:2011 г.), така че в началото на 2012 г. (или веднага щом потребителят поиска преглед на месец 2012+) можете да генерирате бъдещите събития.
Това има два големи недостатъка:
- Вашата база данни има данни за цяла година. Въпреки това, ако добавянето на данни за цяла година развали производителността ви, вашата система вероятно е с недостатъчна мощност. (Изглежда, че е изискване приложението за календар да може да обработва дати за много години)
- В края на хоризонта на събитията трябва да генерирате бъдещите дати за повтарящи се събития.
Предимствата (IMO), които надделяват над недостатъците:
- По-лесна математика при показване на календара. Използвайки метода на Тим по-горе, ако потребителят зареди 18 декември 2011 г., как ще изчислите кои повтарящи се събития трябва да бъдат поставени на този ден? Ще бъдете принудени да преглеждате ВСЯКО повтарящо се събитие всеки път, когато показвате дата. Компромисът е недостатък номер 1, който според мен е по-доброто решение от необходимостта от повторение на тези изчисления.
- Можете да редактирате конкретни екземпляри на събитие. Използвайки метода на Тим, ако среща се случи на празник и потребителят я промени с предишния ден, как бихте го направили? Използвайки описания тук метод за едно записване на събитие, можете просто да промените този запис за събитието, като лесно премествате единични събития в календара.
