Eu apenas criaria uma entrada para cada recorrência do evento, para algum horizonte. No entanto, isso significa que você precisará de outra tabela que possa usar para projetar as datas se elas ultrapassarem a data do horizonte. Ou seja, você precisará de uma tabela de eventos que contenha um registro para cada ocorrência de um evento repetido (1 de janeiro, 8 de janeiro, 15 de janeiro, ... até dezembro) e uma tabela com cada registro disponível para semear anos futuros (iniciar data:1º de janeiro; repetição:7; até:2011) para que no início de 2012 (ou assim que o usuário solicitar uma visualização de um mês de 2012+) você possa gerar os eventos futuros.
Isso tem duas grandes desvantagens:
- Seu banco de dados tem dados de um ano inteiro. No entanto, se adicionar um ano inteiro de dados arruinar seu desempenho, seu sistema provavelmente está com pouca potência. (Parece um requisito que um aplicativo de calendário seja capaz de lidar com datas de muitos anos)
- No final do horizonte de eventos, você precisa gerar as datas futuras para eventos recorrentes.
As vantagens (IMO) que superam as desvantagens:
- Matemática mais fácil ao exibir o calendário. Usando o método de Tim, acima, se o usuário carregar 18 de dezembro de 2011, como você vai calcular quais eventos recorrentes devem ser colocados naquele dia? Você será forçado a percorrer TODOS os eventos recorrentes toda vez que exibir uma data. A desvantagem é a desvantagem nº 1, que eu acho que é a melhor solução do que ter que refazer esses cálculos.
- Você pode editar instâncias específicas de um evento. Usando o método de Tim, se uma reunião ocorresse em um feriado e o usuário a alterasse para o dia anterior, como você faria isso? Usando o método de uma entrada por evento descrito aqui, você pode simplesmente modificar esse registro para o evento, movendo facilmente ocorrências únicas no calendário.
