c# - usar - ¿Debo almacenar fechas o reglas de repetición en mi base de datos al crear una aplicación de calendario?

google calendar para pc (7)

Definitivamente usaría tu segunda opción. Use diferentes opciones de recurrencia, guárdelo por separado y calcule sobre la marcha. Almacenar todas esas fechas sería un cargamento de datos que no es necesario.

Aquí hay una buena respuesta para complementar su pregunta.
¿Estructura de datos para almacenar eventos recurrentes?

Además, como nota al margen. Comencé a almacenar todo como hora UTC para que tenga una línea de base común si alguna vez necesita usar múltiples zonas horarias.

Estoy creando una aplicación de sitio web de calendario ( ASP.NET MVC ) (piense en una versión simple de Outlook) y quiero comenzar a respaldar eventos de calendario que son recurrentes (mensuales, anuales, etc.)

ahora mismo estoy almacenando fechas reales en mi pero quería averiguar si, con periodicidad, tiene sentido continuar almacenando fechas (con algún corte obvio), o debo almacenar las opciones de recurrencia y generar las fechas sobre la marcha .

Me hizo pensar en cómo Outlook, Google Mail, etc. hace este o cualquier otro servicio que admita elementos de calendario recurrentes.

¿Hay alguna sugerencia sobre esto?

Necesita almacenar algunos de ellos con seguridad. El usuario puede editar uno de los eventos, dejando a otros intactos (probablemente se encontró con la pregunta: "¿Desea editar todos los eventos recurrentes o solo este?" En algunos calendarios, es decir, Windows Mobile).

También es posible que desee almacenar eventos pasados y no eliminarlos cuando el usuario elimine el evento recurrente.

Si almacena todos los demás o los genera es un detalle de implementación. Preferiría generarlos, si es posible.

En cualquier caso, querrá tener algún ID del evento recurrente almacenado con cada evento, además de un indicador que le indica si el evento se modificó más tarde. O en un enfoque más complicado, un indicador para cada propiedad de evento que dice, si es el valor predeterminado (del evento recurrente) o si se modificó para esta instancia en particular. Lo necesitará cuando el usuario decida editar el evento recurrente.

Separe sus datos en dos partes: los datos "canónicos" (la regla de recurrencia) y los "servicios" (fechas generadas; solo lectura, aparte de la regeneración). Si los datos canónicos cambian, regenere los datos "de servicio" en ese punto. Para las repeticiones infinitas, conserve cierta cantidad de instancias y genere más si se acaba (por ejemplo, si el usuario mira su calendario para 2020).

Si tuviera una velocidad de procesador infinita, solo necesitaría los datos canónicos, pero en realidad, hacer todo el procesamiento de fecha / hora para todas las reglas de repetición en cada vista de página probablemente lleve demasiado tiempo ... de algún almacenamiento (y complejidad) para guardar ese cálculo repetido. El almacenamiento suele ser bastante barato, en comparación con el cálculo requerido para una gran cantidad de eventos. Si solo necesita almacenar las fechas de los eventos, eso es realmente muy barato: podría usar fácilmente un entero de 4 bytes para representar una fecha y luego generar una fecha / hora completa a partir de eso, asumiendo que sus recurrencias se basan en la fecha. Para las recurrencias basadas en el tiempo (por ejemplo, "cada tres horas"), podría utilizar instantes UTC completos: 8 bytes representarán eso hasta una resolución bastante fina durante el tiempo que sea probable.

Sin embargo, debe tener cuidado con el mantenimiento de la validez: si una reunión recurrente cambia hoy , eso no cambia cuando sucedió en el pasado ... así que probablemente también desee tener datos de solo lectura canónicos sobre cuándo ocurrieron las recurrencias. Obviamente, no querrá que eso se quede con el pasado para siempre, por lo que probablemente desee "recolectar basura" de eventos que tengan más de unos pocos años, dependiendo de las limitaciones de almacenamiento.

Es posible que también necesite la capacidad de agregar notas y excepciones (por ejemplo, "la reunión no se realiza hoy debido a un día festivo" o "se trasladó a las 4 p.m.") por cada evento. Eso se vuelve realmente divertido cuando cambia la repetición: si cambia "todos los lunes" a "todos los martes", ¿guarda las excepciones o no? ¿Cómo igualas las excepciones cuando cambias de "todos los días" a "todas las semanas"? Estas no son preguntas que están directamente relacionadas con el almacenamiento, pero las decisiones de almacenamiento afectarán la facilidad con la que se implementará cualquier política que decida.

Tendrá que manejar por separado eventos y ocurrencias.

EVENT WISE: Para los eventos, deberá almacenar las reglas de repetición (que pueden ser una regla como la especificada por rfc5545 pero también un conjunto explícito de fechas como rdate en rfc5545) pero también excepciones (consulte la fecha de caducidad de rfc5545 y posiblemente la regla de rfc2445) . También deberá realizar un seguimiento de los cambios en esas reglas: los cambios en la fecha y la fecha no son un problema cuando se producen en el futuro y se ignoran en fechas pasadas. Los cambios en la regla son más complicados ya que afectan las ocurrencias previas. Mi preferencia personal es agregar una propiedad específica para la regla antigua y la nueva para especificar sus respectivas fechas de inicio y finalización de validez.

Si el evento tiene un intervalo de tiempo limitado (por ejemplo, la propiedad COUNT o UNTIL está presente), debe almacenar su inicio y fin en la tabla para permitir una consulta más sencilla de los eventos (especialmente cuando se buscan incidencias fuera de la ventana de tiempo precalculada (ver más abajo). puede ayudar a reducir el número de eventos para los cuales se debe rehacer el cálculo).

OCURRENCIAS SENCILLAS: para las ocurrencias, debe almacenar las instancias dentro de una ventana predefinida alrededor de las presentes (por ejemplo, +/- 6 meses o 12 meses y se calcula de manera regular) y mantener registros de esto para permitir el nuevo cálculo si sus usuarios desean ver más en el futuro (por cuestiones de rendimiento). También debe considerar la posibilidad de calcular el índice (ID-RECURRENCIA) para facilitar la búsqueda de la próxima aparición.

menos en el back-end pero más en el front-end también debe hacer un seguimiento de los cambios tzid para preguntar al usuario si un evento que se programó en un tzid dado si está destinado a permanecer en la zona horaria actual debe ser actualizado (piense en alguien en la isla de Samoa que había programado una reunión el viernes 30 de diciembre de 2011 antes de que el país decidiera que este día no existiría), también puede preguntar si un evento que ocurre durante el horario de verano está destinado a "nunca". suceder "o" suceder dos veces "(más sobre este tema here )

Nota: es posible que desee considerar el soporte más allá de lo que se define en rfc5545 en términos de reglas de repetición y también agregar soporte para reglas religiosas recurrentes ( consulte la introducción de USNO a los calendarios o la versión impresa de "Calificaciones geométricas" (Tercera edición) de E. Reingol y N Dershowitz).

Como pregunta acerca de la implementación existente, puede consultar fácilmente el esquema de la base de datos de sunbird (sqlite) o del servidor de calendario y contactos de código abierto de Apple , una lista más completa de los proyectos de código abierto existentes para los servidores caldav (que probablemente sea un subconjunto de lo que Usted está buscando) está disponible here

Tenga en cuenta que la mayoría de las respuestas se inclinan a guardar los datos generados Pero asegúrese de considerar su caso de uso.

En los días en que mis servidores estaban limitados por IO con mucha CPU no haciendo nada. Hoy en día tienes SSD (si puedes pagarlo, de lo contrario, te quedas con una vieja hd giratoria), pero ten en cuenta que el número de núcleos también ha aumentado.

Lo bueno de este tipo de cálculos es que puede dividirlos fácilmente y entregarlos a sus muchos núcleos o incluso a algunos servidores baratos en una red local. A menudo es más barato que configurar un clúster nosql o ir en la forma de clúster de base de datos completa.

Y la alternativa también puede ser un caché, solo caché su vista de calendario, no hay necesidad de hacer todos los cálculos cada vez que nada ha cambiado.

Pero como se dice depende de su caso de uso. No solo siga las respuestas anteriores, sino realice sus propios cálculos si tiene tiempo y toma una decisión.

Tuve que construir un sistema que funcionara con la programación e hicimos ambas cosas. Esto es lo que teníamos

Un conjunto de tablas que mantuvieron un registro del horario.
una tabla que hizo un seguimiento de las instancias anteriores de la programación (cuando realmente ocurrieron)
una tabla que realiza un seguimiento de la última y la siguiente instancia (cuando el próximo elemento debe ocurrir según la última vez) No necesita esta tabla, pero la usamos, porque de lo contrario estaría calculando constantemente si un elemento debería ocurriendo ahora

Con la programación, las cosas pueden ser realmente complicadas porque debe recordar que, en cualquier momento, la programación puede cambiar. Además, un elemento puede vencer cuando la aplicación no se está ejecutando, y cuando se inicia de nuevo, debe saber cómo identificar los elementos vencidos.

Además, nos aseguramos de que las tablas que realizaban un seguimiento del calendario real estuvieran solas. La razón de esto es que esos eran el conjunto de tablas más complejo del sistema y queríamos poder reutilizarlos para que pudieran usarse para diferentes cosas que necesitaban programación. Como el envío de correos electrónicos de administración, el envío de notificaciones y el mantenimiento del servidor, como la limpieza de archivos de registro.

Tuve un problema similar en una aplicación web que hice hace unos años (puede que ahora haya una mejor manera :)). Quería incluir un programador que tuviera toda la funcionalidad de eventos recurrentes, tiempo de manejo, días, semanas, meses, años y excepciones, para poder tener reglas como:

1) Todos los días a las 10am excepto los miércoles

2) Cada 2 horas con un máximo de 4 iteraciones por día.

3) Cada primer lunes del mes

etc.

El almacenamiento de las fechas / horas recurrentes fue posible, pero inflexible. Cada iteración de su evento cambia cuando el "máximo" sería. ¿Y qué tan lejos te ves?

Al final escribí una clase de programación personalizada que podía leer y escribir en una cadena. Esta fue la cadena que se almacenó en la base de datos y luego se puede llamar a una función simple para averiguar cuándo es la próxima aparición.