Po prostu tworzyłbym wpis dla każdego powtórzenia wydarzenia, aż do jakiegoś horyzontu. Oznacza to jednak, że będziesz potrzebować innej tabeli, której możesz użyć do projekcji dat, jeśli przechodzą one poza datę horyzontu. Oznacza to, że będziesz potrzebować tabeli zdarzeń zawierającej jeden rekord dla każdego wystąpienia powtarzającego się zdarzenia (od 1 stycznia, 8 stycznia, od 15 stycznia do grudnia) oraz tabeli z każdym rekordem dostępnym do inicjowania przyszłych lat (początek data:1 stycznia; powtórz:7; do:2011), aby na początku 2012 r. (lub gdy tylko użytkownik poprosi o widok miesiąca 2012+) można wygenerować przyszłe zdarzenia.
Ma to dwie duże wady:
- Twoja baza danych zawiera dane z całego roku. Jeśli jednak dodanie danych z całego roku zrujnuje twoją wydajność, twój system prawdopodobnie jest zbyt słaby. (Wydaje się, że aplikacja kalendarza musi obsługiwać daty z wielu lat)
- Na końcu horyzontu zdarzeń musisz wygenerować przyszłe daty dla wydarzeń cyklicznych.
Zalety (IMO), które przeważają nad wadami:
- Łatwiejsza matematyka podczas wyświetlania kalendarza. Używając powyższej metody Tima, jeśli użytkownik wczyta 18 grudnia 2011 r., w jaki sposób obliczysz, które wydarzenia cykliczne powinny zostać umieszczone w tym dniu? Będziesz zmuszony przejść przez KAŻDE cykliczne wydarzenie za każdym razem, gdy wyświetlisz datę. Kompromis jest wadą nr 1, która moim zdaniem jest lepszym rozwiązaniem niż konieczność ponownego wykonywania tych obliczeń.
- Możesz edytować określone wystąpienia wydarzenia. Stosując metodę Tima, gdyby spotkanie miało miejsce w święto, a użytkownik zmienił je na dzień poprzedni, jak byś to w ogóle zrobił? Korzystając z opisanej tutaj metody jeden wpis na wydarzenie, możesz po prostu zmodyfikować ten rekord wydarzenia, łatwo przenosząc pojedyncze wystąpienia w kalendarzu.
