Mam za zadanie oprogramować ala "kalendarz" w którym jedna z funkcjonalności to możliwość tworzenia wpisów występujących cyklicznie.
Przykładowo dodajemy "Spotkania klasowe dnia 2010-09-02 18:00" -> "Powtórz co miesiąc" co spowoduje, że wydarzenie wystąpi w takich datach jak 2010-10-02 18:00, 2010-11-02 18:00 itd

Jak to zapisać w bazie to bym wiedział (nawet korzystając ze standardu http://en.wikipedia.org/wiki/Iso8601#Durations )
Tylko teraz jak sprytnie pobrać zdarzenia uwzględniąjąc ich cykliczność.
Rozwiązaniem byłoby generowanie zdarzeń naprzód ale chciałbym tego uniknąć.

Nie wiem czy to by Ci odpowiadało, ale dla dat cyklicznych bym osobną tabelę zrobił i w niej trzymał te "dynamiczne". Sam niedawno miałem problem z dynamicznym dopasowywaniem grup użytkowników do mailingu. O ile zwykłe newslettery są oparte o sztywne przypisanie userów do określonych grup i wybiera się przy wysyłce grupę to ja miałem problem by robić to wobec grup dynamicznie zmieniających się. Ostatecznie tuż przed samą wysyłką wywołuję metodę, która do kolejki wrzuca listę userów wedle spreparowanego zapytania. Mykiem było zdefiniowanie grup, gdzie z tego powodu doszły 2 kolumny. Jedna określała typ grupy ( użytkownicy zapisani z newslettera normalnie albo dynamicznie dobierani z bazy ), a druga kryteria dynamicznego wyboru. U Ciebie odpowiednikiem byłoby 'static' (jednorazowe zdarzenia) i 'cyclic' (zdarzenia cykliczne), zaś kryterium częstotliwość zdarzenia (daily, monthly czy wariacje na temat co ileś dni). Ta druga jest niepusta tylko przy cyclic. Dopisywanie dat cyklicznych wiązało by się z przeliczaniem dat danego usera i sprawdzaniem mieszczenia się krotności dat w obserwowanym przedziale czasowym. Można by to zrobić na zasadzie "uzupełnij daty o te pasujące, których wciąż nie ma" z crona co ileś godzin w przód, usuwając zbyt stare jednocześnie, by nie zapchać bazy.

To o czym mówisz jest jasne i jest to tylko potwierdzenie mojego pomysłu w którym uzupełniałbym listę po dodaniu, edycji zdarzeń cyklicznych. A właśnie tej aktualizacji chciałbym w jakiś sposób uniknąć o ile to możliwe.
Np w telefonach jest możliwość ustawienia cykliczności wpisu. Może ktoś wie jak to działa?

Jak tam to działa to nie wiem, ale sądzę, że mają datę bazową i spośród wszystkich cyklicznych, w locie przeliczają, które pasują do wybranego okresu. Komórki i tak ograniczają się do wyświetlania jednego miesiąca, więc nawet kilkaset wpisów dynamicznych (mało kto tyle wrzuci) do obróbki nie będzie problemem. Dorzuci się w razie czego w cache i po sprawie, żeby w trakcie jednej sesji nie liczyć przy łażeniu tam i z powrotem po miesiącach za każdym razem. Poza tym zwróć uwagę na jedno... Zdarzenia cykliczne są edytowalne tylko w zakresie głównego, bazowego wpisu. Jego edycja modyfikuje wszystkie. Nie da się edytować któregoś tam bez skutków ubocznych. Wyjście z kalendarza bowiem "zresetuje" ustawienia tego pojedynczego jeśli nie zapiszesz go do bazy. Co gorsza możesz zapisać, ale co zrobi po powrocie baza jeśli cache usunięto?Będzie pamiętała ten zachowany wyjątek, ale i stworzy na nowo pasujące do cyklu, co tworzy wyjątek i wpis z jakiego powstał obok siebie, co też jest niedopuszczalne. One muszą być z jakimś wyprzedzeniem generowane i zapisywane jako osobne siłą rzeczy. I tak źle i tak niedobrze. Bo chyba nie będziesz przechowywał informacji 'wszystkie pasują do wzorca cyklu, ale X oraz Y nie i mają one czas ustawiony na...'

Ja cykliczność realizuję z użyciem klasy bosjqmCronParser, dzięki której cykliczność określam w postaci zbliżonej do wpisów crona. W momencie wykonania zadania na dany dzień wyznaczam datę następnego zadania i zapisuję ją do bazy danych. Generalnie: to się sprawdza Jednak samym SQLem nie pobierzesz harmonogramu zadań z uwzględnieniem wszystkich cyklicznych - bez generowania dat w przód się nie obejdzie, co jednak będzie upierdliwe Zawsze przecież będziesz miał ostatnią datę, dla której wygenerujesz harmonogram zadania więc zawsze będzie prawdopodobne, że wybierzesz taki harmonogram do pokazania, który owego zadania nie będzie uwzględniał.