¿Cómo deben almacenarse las tareas de calendario repetitivas en la base de datos?

Podrías hacer una tabla separada para que vuelva a ocurrir. Pero, honestamente, simplemente lo pondría en la misma tabla con un campo de tipo.

Algo como esto:

ID - Int Pk

TaskDescription - TEXT

Type - Text - (Re-Occurring, or Single Occurrence) 

Due- TimeStamp - for Single Occurrence is the Date time

LastTimeCompleted - Time Stamp

ReoccurringUnit - Text - "Days", Weeks, Month, Ext

ReoccurringEveryX - Int - Reoccurring interval 

Además del comentario de S.Lott, Martin Fowler - Eventos recurrentes para calendarios PDF puede ayudarlo (I Lo encontré un poco difícil).

También tenga en cuenta que varias herramientas de UI ofrecen la función que está describiendo de manera inmediata (con un modelo de tarea simple). Consideraría este problema como un problema de diseño de base de datos difícil de resolver sin tales herramientas.

En mi opinión, hay dos opciones:

• Almacene una gran cantidad de filas iguales para los artículos recurrentes, sin embargo, tienen que finalizar (ya sea hasta la fecha final o un número finito de artículos), y deben marcarse como un artículo recurrente. Cuando cambias el evento, debes actualizarlos todos, pero cuando quieres desviarte una vez, simplemente puedes "romper" la conexión entre un evento y convertirlo en un evento normal.
• Almacene el evento como un elemento recurrente, con un cierto esquema de repetición, y calcule para una fecha determinada los elementos recurrentes vencen en la fecha determinada. Esto da la posibilidad de repetición infinita.

Si este es un proyecto personal y solo desea una forma de almacenar sus tareas, le recomiendo TaskCoach . Es una aplicación de escritorio, multiplataforma, de código abierto, fácil de comenzar y con muy buenas características.

En caso de que esté desarrollando una aplicación de tareas, la forma más probable es agregar una nueva fila para cada tarea recurrente. La lógica es que cada tarea es una entidad separada en sí misma y debe completarse antes de que la misma tarea se inicie al día siguiente. Si solo lo incrementa, simplemente no puede capturar el historial de la tarea.

En caso de que sienta que solo le daría una gran lista si no se completaran algunas tareas, podría desencadenar un evento una vez que se complete la tarea recurrente para que la nueva tarea se genere como una nueva fila solo cuando La tarea está marcada como completada. Según lo sugerido por los imbéciles, podría usar una tabla separada con una marca para las tareas recurrentes en la tabla original junto con los datos para la recurrencia (días, semanas, tiempo recurrente), de modo que podría tener un simple script que podría generar las tareas recurrentes basadas en Fecha o condición o por etiqueta.

Pero si está seguro de que la tarea es seguramente repetitiva sin ningún cambio (como un pincel diario) y no necesita un seguimiento extenso, puede probar la siguiente estructura

• Bandera de periodicidad: para indicar que la tarea es recurrente
• Período de repetición: día, semana, mes
• Número de tareas creadas: esto incrementaría la tarea según el período de repetición. Entonces, si la tarea comienza hoy y tiene un período recurrente de un día, solo se incrementará en uno mañana
• Número de tareas completadas: esto aumentaría si la tarea se completa

La lógica es la diferencia entre las tareas completadas y las tareas creadas siempre debe ser el período de repetición si la tarea siempre se completa. Por lo tanto, dividir la diferencia de días por período recurrente le daría una indicación de cuánto tiempo ha estado pendiente la tarea.

Gracias a Kareem por señalar esto

En mi humilde opinión, las aplicaciones de tareas son difíciles de crear para las personas en general.

Por mucho, la operación más frecuente será enumerar todos los eventos que ocurren en un período de tiempo. Así que optimice sus datos para que esa pregunta pueda ser respondida por una simple consulta SQL. Me gustaría crear dos tablas:

CREATE TABLE events(start TIMESTAMP, end TIMESTAMP, name TEXT, user_id LONG,
                    recurrence_id LONG, ...);
CREATE TABLE recurrences(id LONG, start TIMESTAMP, end TIMESTAMP, name TEXT, 
                         frequency ...);

Indexe la tabla de eventos por hora de inicio y finalización. Entonces todas las consultas pueden ser respondidas desde la tabla de eventos muy rápidamente. Cuando se edita una repetición, simplemente elimine y vuelva a crear todos los eventos correspondientes.

Este consejo se repite descaradamente de un libro de Tom Kite.

Las tareas repetidas deben tener una fecha de inicio y una fecha de finalización. Para una tarea de fecha única serían la misma fecha.

Cree algún tipo de tabla de "Fechas" que tenga un registro para cada día que crea que es relevante desde el inicio de sus necesidades hasta el futuro que desee: 12/31/2100 por ejemplo y conviértalo a su formato.

Una consulta podría tener el siguiente aspecto:

Select 
  t.id
  , t.label
  , d.UnixDate
from Tasks as t
inner join Dates as d
on d.UnixDate >= t.StartDate
  and d.UnixDate <= t.EndDate
where t.id = [ID Param]

He hecho algo similar hace años implementando una interfaz como el Programador de tareas de Windows y básicamente para cada tarea que tiene StartDate, EndDate (puede ser nula), StartTime y RecurringDays que contiene días de la semana en que se debe programar la tarea.

Puede usar dos tablas: una para la descripción de las tareas, la otra para su estado (hecho / no hecho, y otra información: tiempo empleado, estado de salida, ubicación del archivo de registro, etc.) La tabla de descripción contendría el nombre de la tarea y la fecha o frecuencia con la que se debe ejecutar: solo habrá una fila por tarea. Todos los días, un proceso completaría la tabla de estado para las tareas a realizar hoy, desde la tabla de descripción (puede completar una semana o un mes antes).

La generación de la tabla de estado le brinda toda la flexibilidad que desea para la frecuencia (por ejemplo, "todos los días de la semana, excepto los días festivos del país X", incluso podría almacenarse como una cadena). Tener una tabla de estado le permite verificar si las tareas fallan o con qué frecuencia (por ejemplo: "Se suponía que debía ejecutarme todos los días: ¿con qué frecuencia tenía tiempo para hacerlo?").