La mejor manera de desarrollar/administrar/diseñar tareas recurrentes/calendario

Question

Un ejemplo de lo que estoy hablando es similar a Google Calendar. Cuando se crea una nueva tarea recurrente.

Después de crear la "plantilla" de tareas periódicas, en la que se basan todas las tareas individuales, ¿crea todas las tareas individuales y las almacena en la base de datos? ¿o simplemente almacena los eventos recurrentes "plantilla" y sus excepciones?

Si el usuario solicita una vista de "mes" y desea mostrar todos los eventos/tareas, parece que crear la salida en tiempo real a partir de la plantilla, e incluir todas las excepciones sería mucho más recurso intensivo, entonces, si cada tarea recurrente individual se creó a partir de la plantilla y se insertó en la base de datos.

Esto haría que la búsqueda/clasificación, etc., sea mucho más fácil también.

¿Alguien ha creado algo así antes? ideas?

Answer 1

Almacenar todo en la base de datos.

Desea tener una tabla de "Plantilla de tarea" y una tabla de "Tarea" donde hay una relación de uno a muchos.

Cuando el usuario indica que quiere que se repita una tarea, cree un registro de "Plantilla de tarea" y luego cree tantas "Tareas" como el usuario indique (no permita que un usuario cree tareas demasiado lejanas en el futuro) Cada tarea está vinculada a la plantilla de tareas a través de una clave externa. La idea es que SQL será más eficiente en la administración de estos registros que intentar hacer todo esto en código basado en una plantilla. De esta manera, tendrá más opciones cuando clasifique y filtre sus datos. Después de todo, escribir una consulta SQL es más fácil que escribir, probar y mantener una función PHP que manipule los datos.

Algunos otros consejos que le daría es:

• tratar de conseguir una gran cantidad de información en su historia "plantilla de tarea". Mantenga el número de tareas que cubre la plantilla, la fecha de finalización de la última tarea, el tiempo transcurrido entre la primera y la última, etc. Este "metadato" puede ayudarlo a ahorrar tiempo de consulta cuando busca ordenar y filtrar Tareas.
• Ponga un índice en el campo Fecha y FK, esto también ayudará a consultar el tiempo.
• Acabo de crear dos aplicaciones de calendario en el trabajo que fueron muy bien recibidas por los jefes. Utilicé el complemento JQuery "FullCalendar" (http://arshaw.com/fullcalendar/). Utilicé JQuery AJAX para manejar la mayoría de mis eventos, y había incorporado soporte para las vistas de Mes, Día y Semana.

Answer 2

Si el usuario solicita una vista de "mes" y desea mostrar todos los eventos/tareas, parece que crear la salida en tiempo real de la plantilla, e incluir todas las excepciones sería una muchos más recursos intensivos que si cada tarea recurrente individual se creara a partir de la plantilla y se insertara en la base de datos.

No estoy de acuerdo con eso. ¿Qué pasa si una tarea se repite todos los sábados durante los próximos 7 años ... ¿Y si hubiera muchas de estas tareas repetitivas? Eso le costaría mucho espacio de desperdicio. Por lo tanto, creo que es mejor guardar una tarea recurrente como solo un registro + un registro para cada excepción (ya que hay menos excepciones que las recurrencias).

Pues bien, el único problema que queda es cómo configurar una consulta para seleccionar cada tarea (aún pensando Abou eso)

Answer 3

que pasaron por el mismo problema hace un tiempo y lugar de reinventar la rueda, utilicé Google API de calendario. (http://code.google.com/apis/calendar/data/2.0/developers_guide.html)

Crea una cuenta de Google y accede a la información del calendario. Hay API para crear/editar/borrar una entrada recurrente. Además, puede especificar una información de fecha/hora y una consulta para eventos coincidentes.

Cuando crea un evento en Google Calendar, recibirá un token/id que puede almacenar en su propia base de datos y hacer referencia a él en el contexto de la aplicación.

Answer 4

Para eventos recurrentes hice lo siguiente hace un tiempo:

1. Cuando un usuario introduce un evento a Almacené estilo de fecha GNU patrón de fecha del evento - la palabra clave para PHP es relative date formats.

2. Luego comencé creando eventos para, p. Ej. el próximo año. Y creé registros reales donde convertí la fecha relativa a una real, p. "cada primer lunes" a "mm-dd-YYYY". Esto me permitió mostrarlos y también permitirle al usuario, p. mover un solo evento o cancelar uno, etc.

3. Averiguar qué tan lejos llegar al futuro: mi idea era crear eventos cuando se navegaban las páginas reales. P.ej. si hubiera creado eventos hasta junio de 2011 y alguien hubiera saltado todo el camino hasta julio de 2011, repetiría mis eventos y los configuraría de forma transparente.

4. Cuando el usuario cambia el patrón relativo, ofrezca actualizar todos los eventos siguientes, a menos que ya tengan un patrón personalizado. Los patrones relativos hacen que sea muy fácil calcular todo eso.