¿Por qué necesitamos una base de datos temporal?

StackOverflow https://stackoverflow.com/questions/800331

  •  03-07-2019
  •  | 
  •  

Pregunta

Estaba leyendo sobre bases de datos temporales y parece que han incorporado aspectos de tiempo. Me pregunto por qué necesitaríamos ese modelo.

¿Qué tan diferente es de un RDBMS normal? ¿No podemos tener una base de datos normal, es decir, RDBMS y decir que tenemos un desencadenante que asocia una marca de tiempo con cada transacción que ocurre? Puede que haya un éxito de rendimiento. Pero sigo siendo escéptico con respecto a las bases de datos temporales que tienen un caso sólido en el mercado.

¿Alguna de las bases de datos actuales admite esta característica?

¿Fue útil?

Solución

Una base de datos temporal almacena de manera eficiente una serie de datos de tiempo, generalmente al tener una escala de tiempo fija (como segundos o incluso milisegundos) y luego almacenar solo los cambios en los datos medidos. Una marca de tiempo en un RDBMS es un valor almacenado discretamente para cada medición, que es muy ineficiente. Una base de datos temporal se usa a menudo en aplicaciones de monitoreo en tiempo real como SCADA. Un sistema bien establecido es la base de datos PI de OSISoft ( http://www.osisoft.com/ ).

Otros consejos

Considere su cita / diario de diario, que va del 1 de enero al 31 de diciembre. Ahora podemos consultar el diario para citas / entradas de diario en cualquier día. Este pedido se denomina tiempo válido . Sin embargo, las citas / entradas generalmente no se insertan en orden.

Supongamos que me gustaría saber qué citas / entradas había en mi diario el 4 de abril. Es decir, todos los registros que existían en mi diario el 4 de abril. Este es el tiempo de transacción .

Dado que las citas / entradas se pueden crear y eliminar, etc. Un registro típico tiene un tiempo de inicio y finalización válido que cubre el período de la entrada y un tiempo de transacción de inicio y finalización que indica el período durante el cual apareció la entrada en el diario.

Este acuerdo es necesario cuando el diario puede sufrir revisión histórica . Supongamos que el 5 de abril me doy cuenta de que la cita que tuve el 14 de febrero ocurrió realmente el 12 de febrero, es decir, descubro un error en mi diario. Puedo corregir el error para corregir la imagen de tiempo válida, pero ahora, mi consulta de lo que era en el diario del 4 de abril sería incorrecto, A MENOS QUE, los tiempos de transacción para citas / entradas también se almacenen. En ese caso, si pregunto en mi diario a partir del 4 de abril, se mostrará una cita el 14 de febrero, pero si pregunto a partir del 6 de abril, se mostrará una cita el 12 de febrero.

Esta función de viaje en el tiempo de una base de datos temporal hace posible registrar información sobre cómo se corrigen los errores en una base de datos. Esto es necesario para una verdadera imagen de auditoría de los datos que registra cuándo se realizaron las revisiones y permite consultas sobre cómo se han revisado los datos a lo largo de tiempo.

La mayor parte de la información comercial se debe almacenar en este esquema bitemporal para proporcionar un verdadero registro de auditoría y maximizar la inteligencia empresarial, de ahí la necesidad de soporte en una base de datos relacional. Observe que cada elemento de datos ocupa un cuadrado (posiblemente ilimitado) en el modelo de tiempo bidimensional, razón por la cual las personas a menudo usan un índice GIST para implementar la indexación bitemporal. El problema aquí es que un índice GIST está realmente diseñado para datos geográficos y los requisitos para los datos temporales son algo diferentes.

Las restricciones de exclusión de PostgreSQL 9.0 deberían proporcionar nuevas formas de organizar datos temporales, por ejemplo. Los PERÍODOS de transacción y de tiempo válido no deben superponerse para la misma tupla.

Tal como lo entiendo (y sobre simplificando enormemente), una base de datos temporal registra hechos sobre cuándo los datos eran válidos, así como los datos en sí, y le permite consultar los aspectos temporales. Usted termina tratando con tablas de 'tiempo válido' y 'tiempo de transacción', o 'tablas bitemporales' que involucran aspectos de 'tiempo válido' y 'tiempo de transacción'. Debería considerar leer cualquiera de estos dos libros:

Las bases de datos temporales se usan a menudo en la industria de servicios financieros. Una razón es que rara vez (si es que alguna vez) se le permite eliminar datos, por lo que los campos de tipo ValidFrom - ValidTo se usan en los registros para proporcionar una indicación de cuándo un registro era correcto.

¿Aparte de leer la Artículo de Wikipedia ? Una base de datos que mantiene un " registro de auditoría " o un registro de transacciones similar tendrá algunas propiedades de ser " temporal " ;. Si necesita respuestas a las preguntas sobre quién le hizo qué a quién y cuándo , entonces tiene un buen candidato para una base de datos temporal.

Puedes imaginar una base de datos temporal simple que solo registra tu ubicación GPS cada pocos segundos. Las oportunidades para comprimir estos datos son excelentes, una base de datos normal que necesitaría para almacenar una marca de tiempo para cada fila. Si se requiere una gran cantidad de rendimiento, saber que los datos son temporales y que las actualizaciones y eliminaciones en una fila nunca serán necesarias, permite que el programa elimine gran parte de la complejidad heredada en un RDBMS típico.

A pesar de esto, los datos temporales generalmente se almacenan en un RDBMS normal. PostgreSQL, por ejemplo, tiene algunas extensiones temporales , lo que lo hace un poco más fácil.

Dos razones vienen a la mente:

  1. Algunos están optimizados para insertar y leer solo y pueden ofrecer mejoras espectaculares en el rendimiento
  2. Algunos tienen una mejor comprensión del tiempo que el SQL tradicional, lo que permite agrupar las operaciones por segundo, minuto, hora, etc.

Solo una actualización, la base de datos temporal llegará a SQL Server 2016.

Para despejar todas sus dudas por qué se necesita una base de datos temporal, en lugar de configurar con métodos personalizados, y la eficiencia y la amp; SQL Server lo configura sin problemas, ver el video en profundidad y la demostración en Channel9.msdn aquí: https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016

Enlace de MSDN: https: // msdn. microsoft.com/en-us/library/dn935015(v=sql.130).aspx

Actualmente, con la versión CTP2 (beta 2) de SQL Server 2016 puedes jugar con él.

Consulte este video sobre cómo usar las tablas temporales en SQL Server 2016.

Además de " ¿qué cosas nuevas puedo hacer con él " ;, podría ser útil considerar " ¿qué cosas antiguas se unifican? " ;. La base de datos temporal representa una generalización particular de lo normal. Base de datos SQL Como tal, puede darle una solución unificada a problemas que anteriormente parecían no estar relacionados. Por ejemplo:

  • Concurrencia web Cuando su base de datos tiene una interfaz de usuario web que permite a varios usuarios realizar modificaciones estándar de Crear / Actualizar / Eliminar (CRUD), debe enfrentar el problema de cambios simultáneos en la web . Básicamente, debe comprobar que una modificación de datos entrantes no afecte a ningún registro que haya cambiado desde que el usuario vio esos registros por última vez. Pero si tiene una base de datos temporal, posiblemente ya asocie algo como un " ID de revisión " con cada registro (debido a la dificultad de hacer que las marcas de tiempo sean únicas y monotónicamente ascendentes). Si es así, entonces eso se convierte en lo natural, " ya integrado " mecanismo para evitar la saturación de datos de otros usuarios durante las actualizaciones de la base de datos.
  • Registros legales / impositivos El sistema legal (incluidos los impuestos) pone más énfasis en los datos históricos que la mayoría de los programadores. Por lo tanto, a menudo encontrará consejos sobre los esquemas para las facturas y que le advierte que tenga cuidado de eliminar registros o normalizar de forma natural. manera: lo que puede llevar a una incapacidad para responder preguntas legales básicas como "Olvídese de su dirección actual, ¿a qué dirección envió esta factura por correo en 2001?" Con una base de marco temporal, todas las maquinaciones de esos problemas (generalmente son pasos intermedios para tener una base de datos temporal) desaparecen. Solo usa el esquema más natural y elimínelo cuando tenga sentido, sabiendo que siempre puede regresar y responder con precisión las preguntas históricas.

Por otro lado, el modelo temporal en sí está a medio camino para completar el control de revisión, lo que podría inspirar a otras aplicaciones. Por ejemplo, suponga que coloca su propia facilidad temporal sobre SQL y permite la bifurcación, como en los sistemas de control de revisiones. Incluso una ramificación limitada podría facilitar la oferta de " sandboxing " - la capacidad de jugar y modificar la base de datos con abandono sin causar cambios visibles a otros usuarios. Eso facilita el suministro de capacitación de usuarios altamente realista en una base de datos compleja.

La ramificación simple con una facilidad de combinación simple también podría simplificar algunos problemas comunes de flujo de trabajo. Por ejemplo, una organización sin fines de lucro podría tener voluntarios o trabajadores con salarios bajos que ingresan datos. Darle a cada trabajador su propia sucursal podría facilitar que un supervisor pueda revisar su trabajo o mejorarlo (por ejemplo, la desduplificación) antes de fusionarlo en la sucursal principal, donde sería visible para "normal" " usuarios Las sucursales también podrían simplificar los permisos. Si a un usuario solo se le otorga permiso para usar / ver su rama única, no tiene que preocuparse por evitar todas las modificaciones no deseadas posibles; de todos modos, solo fusionarás los cambios que tengan sentido.

Mi comprensión de las bases de datos temporales es que están orientadas a almacenar ciertos tipos de información temporal. Podría simular eso con un RDBMS estándar, pero al usar una base de datos que lo admite, tiene idiotas incorporadas para muchos conceptos y el lenguaje de consulta podría optimizarse para este tipo de consultas.

Para mí, esto es un poco como trabajar con una base de datos específica de GIS en lugar de un RDBMS. Si bien puede incluir coordenadas en un RDBMS de ejecución normal, tener las representaciones adecuadas (por ejemplo, a través de archivos de cuadrícula) puede ser más rápido, y tener primitivas de SQL para cosas como la topología es útil.

Existen bases de datos académicas y algunas comerciales. Timecenter tiene algunos enlaces.

Otro ejemplo de donde una base de datos temporal es útil es donde los datos cambian con el tiempo. Pasé algunos años trabajando para un minorista de electricidad donde almacenamos lecturas de medidores durante 30 minutos en bloques de tiempo. Esas lecturas de los medidores se podrían revisar en cualquier momento, pero aún necesitábamos poder revisar el historial de cambios para las lecturas.

Por lo tanto, tuvimos la última lectura (nuestra 'comprensión actual' del consumo durante los 30 minutos), pero podemos recordar nuestra comprensión histórica del consumo. Cuando tiene datos que se pueden ajustar de tal manera, las bases de datos temporales funcionan bien.

(Habiendo dicho eso, lo grabamos a mano en SQL, pero fue hace un tiempo justo. No tomaría esa decisión en estos días.)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top