¿Qué son las tablas versionadas y cómo se utilizan?
Las tablas versionadas son estructuras dentro de una base de datos SQL que permiten guardar un histórico de cambios realizados a los datos. Estas estructuras son extremadamente útiles para auditorías o para regresar a un punto específico si se necesita revertir algún cambio. Mediante el uso de una tabla versionada, podemos crear un registro histórico que se actualiza automáticamente cada vez que se modifican los datos. Esto significa que cualquier cambio en los datos dentro de la tabla principal se refleja en una tabla histórica.
¿Cómo se crea una tabla versionada?
El proceso de creación de una tabla versionada en SQL implica la creación de columnas especiales como Valid From y Valid To. Estas columnas se utilizan para indicar la vigencia de los datos dentro de la tabla:
CREATETABLE Usuario ( UserId INTPRIMARYKEY, Nombre NVARCHAR(50), ValidFrom DATETIME2 GENERATED ALWAYS ASROWSTART, ValidTo DATETIME2 GENERATED ALWAYS ASROWEND, PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo))WITH(SYSTEM_VERSIONING =ON(HISTORY_TABLE = dbo.UsuarioHistory));
Este script crea una tabla llamada Usuario con un sistema de versionado, lo que permite que cualquier cambio en los datos también se registre en una tabla histórica llamada UsuarioHistory.
¿Cómo se gestionan los datos insertados y actualizados?
Es importante notar que las tablas versionadas únicamente guardan registros de las operaciones UPDATE y DELETE, no de los INSERT. Esto significa que, al realizar un UPDATE, como cambiar el nombre de un usuario en la tabla Usuario, estos cambios se registrarán en la tabla UsuarioHistory.
UPDATE Usuario
SET Nombre ='Roy Rojas R'WHERE UserId =1;
Cómo modificar tablas existentes para incluir versionado
Agregar funcionalidad de versionado a una tabla ya existente también es posible. Supongamos que tenemos una tabla Usuario2 sin un sistema de versionado. Podemos modificarla y agregarle el sistema de gestión de versiones y una tabla histórica correspondiente.
Si en algún momento decides que el versionado ya no es necesario, puedes desactivarlo fácilmente. Esta acción no eliminará el histórico existente; simplemente separará las tablas históricas para que puedas decidir qué hacer con esos datos.
ALTERTABLE Usuario SET(SYSTEM_VERSIONING =OFF);
Con esto, el control de versiones se desactiva y la tabla histórica UsuarioHistory permanecerá intacta, proporcionando flexibilidad para gestionar los datos antiguos.
¿Cuándo deberías utilizar tablas versionadas?
El uso de tablas versionadas es especialmente valioso en situaciones donde se requiere:
Control de versiones detallado, para rastrear cada cambio realizado en los datos.
Auditoría, especialmente en sectores regulados donde el seguimiento de las modificaciones es crucial.
El sorprender a tu equipo con la eficiencia de estas tablas para gestionar datos históricos y cambios automáticamente ayuda en la productividad al liberar a los desarrolladores de manejar manualmente estos registros. Recuerda siempre mantenerte actualizado para optimizar tus procesos de gestión de datos y seguir aprendiendo sobre las nuevas herramientas que ofrece SQL.
Las tablas versionadas son estructuras paralelas, que van a funcionar en el mismo esquema y que van a guardar el historial de cambios, es muy útil para auditoria.
++Uso de tablas versionadas++
Las tablas versionadas suelen ser útiles en escenarios que requieren historial de seguimiento de cambios de datos debido a las enormes ventajas de productividad.
SQL se encarga de administrar los recursos para el control de versiones.
++Escenarios donde usarlas++control de versiones para información crítica
Para regresar a valores anteriores de una forma sencilla.
auditoria de datos
Controlar cuál usuario y en qué momento realizaron cambios en los valores de la tabla.
Pero ¿Cómo retorno a un versión especifica de la tabla versionada? No mostró eso...
Con base en lo mostrado en el video, supongo sería posible corriendo la consulta en el rango (versión) de fecha y luego hacer los updates (aquí el MERGE parece útil) con el resultado a la tabla principal.
Si desactivamos SYSTEM_VERSIONING temporalmente y luego lo reactivamos, ¿Qué ocurre con los datos históricos generados durante ese intervalo? ¿Se pierden o pueden reintegrarse al historial?
¿Trae alguna implicación a nivel de recursos físicos, el uso de tablas versionadas? por ejemplo ¿Un uso excesivo de memoria a procesamiento?
Utilizar tablas versionadas va a depender de las necesidades de tu negocio, pero si son mucho mas eficientes que por ejemplo hacer una bitacora manual ya sea por SP o Triggers. Las tablas versionadas son muy eficientes y se crearon para facilitar el trabajo.
¿No hay ninguna forma de capturar en tablas históricas o versionadas un insert?
No, en ese caso deberias de usar un Trigger
Las tablas versionadas afectan el rendimiento de la consulta de la tabla principal o de las relaciones con otras tablas (JOIN)?
No te van a afectar el rendimiento de la tabla, solamente va a guardar los cambios en esa tabla "historica". La tabla versionada no va a tener relacion con las tablas join que pueda tener la tabla principal por lo que tampoco deberia de afectar. Yo he hecho pruebas insertando 1 millon de registros con y sin tabla versionada y el rendimiento ha sido el mismo. lo unico que hay que tenr cuidado es que eventualmente esta tabla puede crecer mucho si la tabla principal tiene muchos inserts, delete y update, hay que estarla monitoreando. Por eso es importante saber cuando utilizarla.
Es posible utlizar las tablas versionadas en el procedimiento de Deleted, puede detectar cuando se hace una eliminacion, por ejemplo, si es el primer registro ingresado a la tabla y eliminado inmediatamente, se puede tener control de ese evento?
Si claro, te va a guardar en la tabla versionada el último valor registrado en la tabla principal.
Estos son los casos de uso más comunes
para las tablas temporales:
Auditoría. Con tablas temporales puede averiguar qué valores una entidad específica ha tenido en toda su vida.
Cambio de dimensiones lentas en un Data Warehouse. Una tabla versionada del sistema se comporta exactamente como una dimensión de tipo 2 cambiando comportamientos de sus propias tablas En este caso, la tabla de dimensión incluye los campos de fecha inicio de vigencia y fecha fin de vigencia. Estas fechas nos permiten determinar en qué estado estaba la dimensión en cualquier fecha del calendario.
Reparación de corrupciones a nivel de registro. Que sería como una especie de mecanismo de copia de seguridad en una sola tabla.
Eliminación accidental de un registro. Recuperar el archivo de la tabla historial e insertarla de nuevo en la tabla principal.
He trabajado bastante con SQL Server, es la primera vez que me entero de este tema.
Esta clase, si vale oro
¿Este tipo de tablas también se pueden implementar en Azure?
Entiendo que en cierta parte las columnas "ValidFrom" y "validTo" son necesarias para el funcionamiento. Pero es imposible que la tabla "Usuario", NO tenga esas columnas y solo se muestren o representen en la tabla del histórico? Me parece que a la hora de ver información "normal" de usuarios, esa información no te es relevante del todo.
Ya sé que la respuesta es "Pues no selecciones esas columnas XD", pero yo soy partidario de tener cuantas menos columnas mejor.
Gracias.
Las columnas de la tabla versionada las define sql, asi vas a saber en que rango de fechas ese valor edtuvo activo en la tabla principal
Hola,
Al manejar estas tablas las bases de datos van a generar un incremento en su almacenamiento, esto puede volver lento la base?
Para esto tienes que darle buen mantenimiento a tus bases de datos, revisar si los índices estan ordenados. Una base de datos gigante no tiene por que ser lenta. Yo actualmente administro bases de datos con Teras de información y funcionan muy eficientemente.
El uso de tablas versionadas en Querys con INNER JOIN entre otros es igual como una tabla normal?
las tablas versionadas son una tabla nueva, la vas a ver en la lista de tablas de tu base de datos. la cual puedes utiliar de forma independiente
Usar tablas versionadas no impacta en el rendimiento o performance de mis Consultas.
va a depender de como tengas configurada tu base de datos, si es una tabla con muchas tranascciones pues si puede afectar el rendimiento pero no debería de ser significativo. Ahora si tu tabla es grande y tiene muchisimas transacciones puedes notar un crecimiento significativo en tu base de datos.
¿Se puede guardar información adicional como por ejemplo el usuario que realiza la acción?
Al desvincular una tabla histórica de la tabla principal en un sistema de tablas versionadas, los datos recuperados de la tabla histórica permanecen intactos y no se eliminan. La tabla principal ya no tendrá el control de versiones, pero la información histórica seguirá disponible en la tabla desvinculada. Esto permite conservar un historial de cambios sin que afecte la operativa actual de la tabla principal.
triggers VS tablas versionadas
Simplicidad y Mantenimiento:* Las tablas versionadas son más simples de mantener ya que SQL Server se encarga automáticamente de la captura de cambios.
Flexibilidad:* Los triggers son más flexibles y pueden ser personalizados para necesidades específicas, pero requieren más mantenimiento y pueden ser más propensos a errores.
Rendimiento:* Las tablas versionadas generalmente tienen mejor rendimiento porque SQL Server está optimizado para estas operaciones, mientras que los triggers pueden añadir sobrecarga.
Compatibilidad:* Los triggers funcionan en versiones más antiguas de SQL Server, mientras que las tablas versionadas requieren SQL Server 2016 o superior.
También es algo nuevo para mí, pero no quedó claro cómo reversar las tablas versioandas.
Esta funcionalidad me era completamente desconocida. En mi trabajo actual puede ser muy útil porque tenemos muchas tablas de las cuales se requiere realizar un seguimiento de los cambios y, tradicionalmente, se hace un control a través de procedimientos almacenados.