Debo almacenar fechas o reglas de recurrencia en mi base de datos cuando se construye una aplicación de calendario?

Question

Estoy construyendo un sitio web calendario (ASP.NET MVC) aplicación (versión simple de pensar en perspectiva) y quiero empezar a apoyar los eventos del calendario que son recurrentes (mensual, anual, etc.)

en este momento estoy almacenando las fechas reales en mi pero quería averiguar si, con la recurrencia, ¿tiene sentido que siga fechas de tienda (con un poco de corte obvio), o debería almacenar las opciones de repetición y generar las fechas sobre la marcha.

Me puse a pensar cómo Outlook, Gmail, etc hace esto o cualquier otro servicio que soporta elementos de calendario periódicos.

¿Hay alguna sugerencia al respecto?

Answer 1

separar sus datos en dos partes: los datos "canónicos" (la regla de repetición) y "sirven" (generada fechas; de sólo lectura a un lado de la regeneración). Si cambian los datos canónicos, regenerar los datos de "servir" en ese punto. Para las recurrencias infinitas, mantener cierto número de casos y generar más si se han agotado (por ejemplo, si las miradas de los usuarios en su calendario para el año 2020).

Si tuviera la velocidad del procesador infinita, que había sólo necesita los datos canónicos - pero en realidad, hacer todo el procesamiento de la fecha / hora de que todas las reglas de recurrencia en todos vista de la página es probable que sea demasiado tiempo ... por lo que el comercio de algunos de almacenamiento (y complejidad) para guardar que el cálculo repetido. El almacenamiento es por lo general bastante barato, en comparación con el cálculo necesario para un gran número de eventos. Si solamente necesidad de almacenar las fechas de los eventos, que es realmente muy barato - se puede utilizar fácilmente un entero de 4 bytes para representar una fecha, y luego generar una fecha completa / hora a partir de que, asumiendo que su recurrencias son todos basados ??fecha. Para las recurrencias basados ??en el tiempo (por ejemplo, "cada tres horas") que podría instantes llenos UTC - 8 bytes que representará a una resolución fina bastante por el tiempo que es muy probable que la necesidad

.

Es necesario tener cuidado con el mantenimiento de validez sin embargo - si un cambio recurrente de reuniones hoy , que no cambia cuando tiene sucedido en el pasado ... así es probable que desee también Tienes canónica datos de sólo lectura acerca de cuándo ocurrieron recurrencias realidad. Es obvio que no va a querer que para mantener el pasado para siempre, por lo que es probable que desee "limpieza de la memoria" eventos de más de unos pocos años, dependiendo de las limitaciones de almacenamiento.

También puede necesitar la posibilidad de añadir notas y excepciones (por ejemplo, "reunión no se produce hoy en día debido a un día festivo" o "se trasladó a 16:00") en función de cada ocurrencia. Eso se convierte en realmente divertido cuando se cambia la recurrencia - si cambia "cada lunes" a "todos los martes" Cómo se mantiene las excepciones o no? ¿Cómo se puede incluso coincidir las excepciones cuando se cambia de "todos los días" a "todas las semanas"? Estas no son preguntas que son directamente sobre el almacenamiento - pero las decisiones de almacenamiento afectarán a lo fácil que es implementar cualquier política que decida sobre

.

Answer 2

Usted tendrá que manejar por separado eventos y sucesos.

CASO WISE: Para eventos, tendrá que almacenar reglas recurence (que puede ser un RRULE como especificado por rfc5545, sino también un conjunto explícito de fechas como rdate en rfc5545), sino también excepciones (véase EXDATE de rfc5545 y posiblemente exrule como en RFC2445). También tendrá que hacer un seguimiento de los cambios en las reglas: Los cambios en rdate, EXDATE no son un problema cuando se producen en el futuro y para ser ignorados por las fechas anteriores. Los cambios en RRULE son más complicado, ya que afecta las apariciones anteriores. Mi preferencia personal es añadir una propiedad específica para el viejo y el nuevo RRULE para especificar sus respectivas inicio y final de validez.

si el evento tiene un período de tiempo limitado (digamos COUNT o hasta que la propiedad se encuentran presentes) tiene que guardar su comienzo y al final de la tabla para permitir la fácil consulta de eventos (sobre todo en la búsqueda de sucesos fuera de su ventana de tiempo previamente calculado (véase más adelante ), puede ayudar a reducir el número de eventos para los cuales el cálculo debe ser hecho de nuevo).

ACAECIMIENTOS WISE: de ocurrencias que debe guardar las instancias dentro de una ventana predefinida alrededor de la actual (+/- decir 6 meses o 12 meses y se calcula sobre una base regular) y mantener registros de este para permitir la re-cálculo si los usuarios quieren ver más en el futuro (por problemas de rendimiento). también se debe considerar el cálculo del índice (REPETICIÓN-ID) para ayudar a facilitar hallazgo de la siguiente aparición.

menos en el back-end pero más en el front-end que también debe realizar un seguimiento de los cambios TZID para preguntar al usuario si un evento que estaba previsto en un TZID dada si se tiene la intención de estancia en la zona horaria actual de ella es necesario actualizar (piensa en alguien en la isla de Samoa que tenía horario de una reunión el viernes 30 de diciembre 2011 antes el país decidió no existiría este día), de manera similar se puede preguntar si un evento que ocurre durante el horario de verano está destinado a "no pasar" o "pasará dos veces" (más sobre este tema aquí )

Nota: es posible que desee considerar el apoyo más allá de lo que se define en rfc5545 en términos de reglas recurrencia ya la también añadir soporte para normas religiosas recurrentes ( véase la introducción a USNO calendarios o en la impresión 'cálculos de calendario' (tercera edición) de E. Reingol y N. Dershowitz).

que lo preguntas acerca de la aplicación existente, se puede comprobar fácilmente el esquema de la base de Sunbird (SQLite) o de la Calendario de Apple de código abierto y los contactos servidor, una lista más completa de proyectos de código abierto existentes para servidores CalDAV (que es probablemente un subconjunto de lo que busca) está disponible aquí )

Answer 3

he tenido que construir un sistema que funcionaba con la programación y lo hicimos los dos. Aquí está lo que teníamos

• un conjunto de tablas que llevaba la cuenta de la programación.
• una tabla que mantiene un seguimiento de instancias anteriores de la programación (cuando en realidad se produjeron)
• una tabla que mantiene un registro de la última y la próxima instancia (cuando el orden del día se debe a producirse sobre la base de la última vez) No necesita esta tabla, pero lo usamos, porque de lo contrario estaría constantemente calculando si un elemento debe estar ocurriendo ahora

Con la programación, las cosas se pueden poner muy complicado porque hay que recordar que en cualquier punto en el tiempo, el calendario puede cambiar. Además, un elemento puede deberse cuando su aplicación no se está ejecutando, y cuando se pone en marcha de nuevo, lo que necesita saber cómo identificar artículos vencidos.

Además, nos aseguramos de que las tablas que llevaba la cuenta de la programación real quedaron solos. La razón de esto es que esas eran el conjunto más complejo de las tablas en el sistema y que quería ser capaz de volver a utilizarlos de modo que pudieran ser utilizados para diferentes cosas que necesita programación. Tales como envío de correos electrónicos de administración, el envío de notificaciones, y el mantenimiento del servidor, como la limpieza de los archivos de registro.

Answer 4

Sin duda alguna lo usa tu segunda opción. Utilizar diferentes opciones de repetición, almacenarlo por separado y calcular sobre la marcha. Almacenar todas esas fechas sería un bote lleno de datos que no son necesarios.

Aquí hay una buena respuesta para complementar su pregunta.
Estructura de datos para almacenar acontecimientos que se repiten?

Además, como nota al margen. He empezado a almacenar todo el tiempo UTC para que tenga una línea de base común si alguna vez tiene que utilizar múltiples zonas horarias.

Answer 5

He tenido un problema similar en una aplicación web que hice hace unos años (bien puede haber una manera mejor ahora :)). Quería incluir un programador que tenía toda la funcionalidad de eventos recurrentes, tiempo de manejo, días, semanas, meses, años y excepciones, por lo que podría tener reglas como:

1) todos los días a las 10 am exceptuados 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 que se repiten / veces era posible, pero inflexible. Cada iteración de su evento cambia cuando el "máximo" sería. Y hasta qué punto por delante qué miras?

Al final me escribió una clase de planificación personalizada que podía leer y escribir en una cadena. Esta fue la cadena que se almacena en la base de datos y luego una simple función puede ser llamada para averiguar cuándo es la siguiente aparición.

Answer 6

Se necesita almacenar algunos de ellos con seguridad. El poder del usuario editar uno de los eventos, dejando otros intactos. (Probablemente conoció a la pregunta: "? ¿Quieres editar todos los eventos recurrentes o sólo éste" en algunos calendarios, es decir, Windows Mobile)

También puede ser que desee almacenar eventos del pasado y no eliminarlos cuando el usuario elimina el evento recurrente.

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

En cualquier caso, usted querrá tener una identificación del evento recurrente almacenado con cada evento, además de algunos bandera que le dice si el evento se modificó más tarde. O en el enfoque más complicado, una bandera para cada evento revelador propiedad, si se trata de valor predeterminado (desde el evento recurrente) o si se modificó para este caso particular. Lo necesitará cuando el usuario decide editar el evento recurrente.

Answer 7

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

En los días en mis servidores estaban limitados por io con una gran cantidad de CPU no hacer nada. Hoy en día se ha SSD (si no puede pagar esos, de lo contrario su izquierda con un viejo hd hilado), pero nota que el recuento núcleo ha aumentado también.

Lo bueno de este tipo de cálculos es que se puede dividir fácilmente y darles a sus muchos núcleos o incluso a unos pocos servidores baratos en una red local. A menudo más barato que la creación de un cluster nosql o ir en la dirección de clúster de base de datos completa.

y podría ser una alternativa también caché, simplemente almacenar en caché la vista de calendario, no hay necesidad de hacer todos los cálculos cada vez que nada ha cambiado.

Sin embargo, como se ha dicho que depende de su caso de uso. No se limite a seguir las respuestas anteriores, pero hacer sus propios cálculos, si tienes tiempo y de tomar una decisión.