Complemento de eventos recurrentes para el esquema de base de datos CakePHP/PHP y MySQL

Introducción

Hola, he pasado bastante tiempo investigando para encontrar la solución adecuada para eventos recurrentes en un próximo proyecto. He trabajado con eventos y eventos recurrentes antes y nunca he encontrado o desarrollado una solución que me haya gustado. Así que estoy pensando en crear un complemento para CakePHP para manejar la recurrencia.

Tengo dos casos de uso para los que me gustaría usar este complemento/clases:

  1. Eventos recurrentes: vista de calendario o lista
  2. Pagos recurrentes: a veces no quiero usar las pasarelas de pagos recurrentes o quiero recibir notificaciones de próximos pagos, etc.

Estoy seguro de que hay muchos otros casos de uso, pero esos son los dos que encuentro con más frecuencia, en realidad, el esquema de la base de datos y el código fuente básico deberían ser similares, si no completamente reutilizables entre los diversos casos de uso, de todos modos.

Entonces, con lo que necesito ayuda es para decidir el esquema de base de datos apropiado para usar para eventos recurrentes. Tengo dos ideas y creo que cada una tiene sus pros y sus contras, pero necesito decidirme por el mejor enfoque general para la flexibilidad, la mantenibilidad y el rendimiento.

Entonces, en cualquiera de las soluciones, necesito poder agregar, editar, eliminar y enumerar los eventos. Me gustaría poder editar un evento recurrente con la opción de editar o eliminar todos los días en que ocurre el evento o un día específico. Me gustaría tener reglas/opciones de recurrencia similares al calendario de Google. Opciones como diario, semanal, mensual, anual, etc.

Primera idea

Una tabla llamada eventos para almacenar los eventos recurrentes. En este enfoque, necesitaría analizar la opción de recurrencia y esencialmente hacer un bucle y crear un evento individual basado en la opción de recurrencia. Entonces, por ejemplo, si quiero crear un evento llamado "Reunión semanal" con fecha de inicio del 1 de enero de 2012 y fecha de finalización del 31 de diciembre de 2012 que ocurre todos los lunes, crearía 52 registros en la tabla de eventos. Creo que este enfoque sería más difícil de administrar al editar y eliminar y llevaría más tiempo guardar el evento, pero enumerar los datos debería ser tan simple como consultar un rango de fechas. Puede ser una pesadilla si tiene que cambiar la recurrencia de ese evento.

CREATE TABLE `events` (                                                               
      `id` int(10) unsigned NOT NULL AUTO_INCREMENT,                                      
      `parent_id` int(10) unsigned NOT NULL,                                              
      `start_date` datetime NOT NULL,                                                     
      `end_date` datetime NOT NULL,                                                       
      `title` varchar(150) CHARACTER SET latin1 NOT NULL,                                 
      `description` text CHARACTER SET latin1,                                            
      `created` datetime NOT NULL,                                                        
      `modified` datetime NOT NULL,                                                       
      PRIMARY KEY (`id`)                                                                  
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8

Segunda idea

Tenga varias tablas para manejar la recurrencia. Esto eliminaría los problemas de edición y eliminación y el guardado también debería ser más rápido, pero creo que consultar los datos para obtener los eventos sería complejo (pensando que las consultas mysql serán complejas) y más lento. Debo mencionar que este sistema leerá mucho más de lo que escribirá eventos. Pero quiero una solución general que se pueda reutilizar. También puedo usar el almacenamiento en caché para mejorar la lectura, por lo que no es una gran preocupación. Usando el ejemplo anterior en lugar de 52 entradas, solo tendríamos una en la tabla de eventos.

¿No estás seguro del esquema exacto, alguna idea?

Gracias de antemano por su ayuda e ideas! Quiere tener una idea de cómo otros manejan los eventos recurrentes.

preguntado el 27 de julio de 12 a las 17:07

1 Respuestas

CREATE TABLE `events` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `parent_id` int(10) unsigned NOT NULL,
    `title` varchar(150) CHARACTER SET latin1 NOT NULL,
    `description` text CHARACTER SET latin1,
    /** Some fields about how the recurring is applied  **/
   `created` datetime NOT NULL,
   `modified` datetime NOT NULL,
   PRIMARY KEY (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8

CREATE TABLE `event_occurrences` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `event_id` int(10) unsigned NOT NULL,
    `date` DATE NOT NULL,
   PRIMARY KEY (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8

Si los detalles recurrentes, los campos de inicio o fin no se cambian, no hay necesidad de meterse con event_occurrences. Al modificar cualquiera de esos detalles DELETE FROM event_occurrences WHERE event_id=? y luego tener un método que generará event_occurrences para una identificación de evento determinada. El mismo método podría usarse para crear y modificar.

Respondido 27 Jul 12, 18:07

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.