ventajas que español desventajas caracteristicas database temporal-database

database - que - ¿Por qué necesitamos una base de datos temporal?



mongodb español (11)

¿Aparte de leer el 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 hizo qué a quién y cuándo, entonces tiene un buen candidato para una base de datos temporal.

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

¿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 sobre las bases de datos temporales que tienen un caso sólido en el mercado.

¿Alguna de las bases de datos actuales soporta tal característica?

Además de "qué cosas nuevas puedo hacer con él", podría ser útil considerar "¿qué cosas viejas unifica?". La base de datos temporal representa una generalización particular de la base de datos SQL "normal". Como tal, puede brindarle una solución unificada a los problemas que antes parecían no relacionados. Por ejemplo:

  • Concurrencia web Cuando su base de datos tiene una interfaz de usuario web que permite que varios usuarios realicen modificaciones estándar de Crear / Actualizar / Eliminar (CRUD), debe enfrentar el problema de los cambios simultáneos de la web . Básicamente, debe verificar 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 se convierte en el mecanismo natural, "ya incorporado", 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á advice sobre esquemas para facturas y advice para que tenga cuidado de eliminar registros o normalizar de forma natural, lo que puede llevar a una incapacidad para responder preguntas legales básicas como "Olvídese de su dirección actual, qué dirección hizo". ¿Enviaste esta factura por correo a 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 propio modelo temporal está a mitad de 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 el ofrecer "sandboxing": la capacidad de jugar y modificar la base de datos con abandono sin causar cambios visibles a otros usuarios. Esto facilita la capacitación de usuarios altamente realistas en una base de datos compleja.

La ramificación simple con una facilidad de fusió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 realizan la entrada de datos. Darle a cada trabajador su propia sucursal podría facilitar que un supervisor pueda revisar su trabajo o mejorarlo (p. Ej., Desduplicación) antes de fusionarlo en la sucursal principal donde sería visible para los usuarios "normales". Las sucursales también podrían simplificar los permisos. Si a un usuario solo se le concede 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.

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 sobre 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ías considerar leer cualquiera de estos dos libros:

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 ordenamiento se llama el tiempo válido . Sin embargo, las citas / entradas generalmente no se insertan en orden.

Supongamos que me gustaría saber qué citas / entradas estaban 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 la entrada apareció en el diario.

Este arreglo es necesario cuando el diario puede sufrir una 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 realizar consultas sobre cómo se han revisado los datos a lo largo del 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.

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.

Las bases de datos temporales se utilizan 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.

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 integradas 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 podría 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 del medidor se podrían revisar en cualquier momento, pero aún necesitábamos poder mirar hacia atrás en 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 mirar hacia atrás a 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 un momento justo. No tomaría esa decisión en estos días).

Puede imaginar una base de datos temporal simple que solo registre su 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, permitirá 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 facilita esto un poco.

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

Para aclarar todas sus dudas sobre por qué necesita una base de datos temporal, en lugar de configurar con métodos personalizados, y cómo el servidor SQL Server lo configura de manera eficiente y sin problemas, consulte el video y la demostración en profundidad 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.

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

Una base de datos temporal almacena eficientemente una serie temporal de datos, por lo general al tener una escala temporal 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/ ).