Simplemente crearía una entrada para cada recurrencia del evento, hasta algún horizonte. Sin embargo, significa que necesitará otra tabla que pueda usar para proyectar las fechas si se escanean más allá de su fecha de horizonte. Es decir, necesitará una tabla de eventos que contenga un registro para cada ocurrencia de un evento repetido (1 de enero, 8 de enero, 15 de enero, ... hasta diciembre) y una tabla con cada registro disponible para iniciar años futuros (start fecha:1 de enero; repetición:7; hasta:2011) para que a principios de 2012 (o tan pronto como el usuario solicite una vista de un mes de 2012+) pueda generar los eventos futuros.
Esto tiene dos grandes desventajas:
- Su base de datos contiene datos de un año completo. Sin embargo, si agregar los datos de un año completo arruina su rendimiento, es probable que su sistema tenga poca potencia. (Parece un requisito que una aplicación de calendario pueda manejar las fechas de muchos años)
- Al final del horizonte de eventos, debe generar las fechas futuras para los eventos recurrentes.
Las ventajas (OMI) que superan las desventajas:
- Matemáticas más fáciles al mostrar el calendario. Usando el método de Tim, arriba, si el usuario carga el 18 de diciembre de 2011, ¿cómo va a calcular qué eventos recurrentes deben colocarse en ese día? Se verá obligado a recorrer CADA evento recurrente cada vez que muestre una fecha. La compensación es la desventaja n.º 1, que creo que es la mejor solución que tener que rehacer estos cálculos.
- Puede editar instancias específicas de un evento. Usando el método de Tim, si una reunión ocurriera en un día festivo y el usuario la cambiara al día anterior, ¿cómo lo haría? Usando el método de una entrada por evento descrito aquí, podría simplemente modificar ese registro para el evento, moviendo fácilmente las ocurrencias individuales en el calendario.
