sql - Esquema relacional para las expresiones temporales de Fowler

orm scheduling

Question

Martin Fowler define un elegante modelo de objetos para la programación de tareas recurrentes aquí , que se asigna al código OO muy bien. Sin embargo, mapear esto en un esquema de base de datos relacional para la persistencia es complicado.

¿Alguien puede sugerir una combinación de esquema + SQL que encapsula toda la funcionalidad que describe, particularmente en la imagen en la página 11. Los intersecciones y las uniones son bastante obvias, la complejidad radica en representar las ''Expresiones temporales'', que toman parámetros variables y deben interpretarse de manera diferente, y luego combinarlos en un ''Conjunto Temporal''.

Para ser claros, hay muchas maneras de representar el concepto de eventos recurrentes en bases de datos relacionales. Lo que me gustaría es que la opinión de todos sea cómo mapear este modelo en particular.

Algunas posibles opciones:

• Tablas ''Meta'' que definen el número de y el uso de argumentos. Feo, pero probablemente funcione. Sin embargo, solo es probable que exista un número limitado de formas de ''Expresión temporal'', por lo que la flexibilidad extrema que esto ofrece probablemente sea demasiado.
• Alguna forma de herencia de tablas, como es soportado por Postgres (y presumiblemente, otro) RBMS.

La serialización de la lista de parámetros y el almacenamiento del resultado en varchar () no es una solución, ya que ese método evita las consultas basadas en conjuntos :)

Answer 1

SQL es un lenguaje para consultar conjuntos de datos. No admite fácilmente la codificación de operaciones lógicas específicas de dominio. En otras palabras, "regla a evaluar" no es un tipo de datos en SQL. Ese es un concepto orientado a objetos, que tanto los datos como la lógica son componentes de una instancia de objeto.

Así que diría que lo máximo que podría hacer dentro del paradigma de SQL sería almacenar 365 filas, correspondientes a los días del año, y un valor verdadero / falso para determinar si el día correspondiente cumple los criterios de la programación recurrente. Por lo tanto, debe usar la lógica de OO que implementa el modelo de Fowler para realizar el cálculo y almacenar las 365 filas resultantes.

Entonces, cuando necesita saber "¿el día (o cualquier fecha) es parte del cronograma?" es muy fácil buscar la fila apropiada y verificar la columna verdadero / falso. Almacenar 365 filas por año es trivial para cualquier base de datos.

Esto puede parecer una trampa, pero como he dicho, SQL se trata de conjuntos de datos, no de lógica.

Answer 2

Me temo que esta respuesta será un montón de referencias y muy poco código práctico, y ha pasado un tiempo desde la última vez que me metí con esto, pero ...

Creo que las dos tecnologías que desea combinar aquí son ''bases de datos activas'' y ''bases de datos temporales'' .

El primero sería útil para evaluar las reglas y demás, y el segundo es útil para almacenar datos temporales y evaluar cuándo un determinado registro es válido. Ambas son áreas de investigación bastante grandes, pero puede hacer la mayoría de las cosas temporales en SQL sencillo (siempre que su base de datos tenga buen soporte de tiempo). La parte activa es más difícil en SQL, pero PostgreSQL al menos tiene reglas para ayudar con esto. No sé sobre las otras bases de datos, pero la mayoría de ellas tiene soporte de reglas / activadores / restricciones que podrían traducirse a lo que estás buscando.

Las bases de datos activas son bases de datos que pueden reaccionar a los cambios en los hechos que almacena usando reglas. Estas reglas se especifican en los lenguajes específicos de la implementación, pero para las discusiones diarias, las reglas de la condición de evento del evento ( reglas de ECA) son comunes. Para una introducción a los sistemas activos de bases de datos, lea los artículos El Manifiesto del Sistema de Gestión de Base de Datos Activo y los Sistemas de Base de Datos Activos . Para obtener más información sobre las reglas de ECA, consulte Eventos lógicos y Reglas de ECA (las páginas están en orden inverso o_0) y Eventos en un Sistema de base de datos orientado a objetos activos .

El procesamiento de eventos es un caso especial del manejo de reglas que trata sobre cómo manejar eventos compuestos y desencadenar sus acciones de manera apropiada. Una lectura interesante sobre esto son los Eventos Compuestos para Bases de Datos Activas: Semántica, Contextos y Detección y Anatomía de un Detector de Eventos Compuesto . Consulte también el sitio de Procesamiento de eventos complejo y los artículos de wikipedia de Procesamiento de eventos y Eventos complejos .

Las bases de datos temporales pueden verse como una base de datos que puede comprender el tiempo y, en particular, dos tipos específicos de tiempo; tiempo de validez y tiempo de transacción. El tiempo de validez de un registro es el período de tiempo durante el cual ese registro es válido, y el tiempo de transacción de un registro es el tiempo durante el cual está presente en la base de datos. Como una buena introducción práctica recomiendo el libro sobre cómo hacer bases de datos temporales en SQL: Desarrollo de aplicaciones de bases de datos orientadas al tiempo en SQL por Richard T. Snodgrass.

O bien, todo lo que posiblemente desee saber sobre las bases de datos temporales puede leerse en Entradas temporales de bases de datos para Springer Encyclopedia of Database Systems, que es un documento bastante completo (comenzaría en la entrada ''Temporal Database''), pero para comenzar un poco más rápido, consulte el Glosario de la base de datos temporal, que es bastante más fácil de navegar y leer, y el Centro de tiempo del sitio cuyas publicaciones tienen (o tuvieron) enlaces a las publicaciones más destacadas del área.

Entonces, ahora que sabe todo sobre esto, ve rápidamente que la imagen en la página 11 se puede expresar como un evento compuesto, y se puede detectar / evaluar como tal siempre que haya implementado el subconjunto requerido apropiado de un detector de eventos compuesto, y el el resto podría expresarse como entradas en tablas con aspectos temporales :)

Martin Fowler aborda mucho de esto en sus Patrones de cosas que cambian con el tiempo y que resumen muchos patrones relacionados con el tiempo.

Al final, probablemente crearía un esquema de base de datos para la información temporal y usaría las reglas de DB para las partes activas o implementaría esa parte en la aplicación (sin embargo, habrá dragones). Si utiliza PostgreSQL, los mecanismos de reglas se describen en la parte del Sistema de reglas de los documentos.

Mucho para leer, pero si entiendes todo esto, tu valor neto profesional puede subir un poco :)

Además, los buenos términos para google son ''base de datos temporal'', ''base de datos activa'', ''regla ECA''.