Cómo versionar esquemas de tablas en Azure Synapse Analytics: paso a paso

João Barros 03 de November de 2026 5 min de lectura

Este tutorial explica cómo implementar un método sencillo para versionar esquemas de tablas en Azure Synapse Analytics, con el fin de mantener un historial y facilitar rollbacks. El enfoque es útil para equipos que modifican tablas en Dedicated SQL Pool o en bases SQL dentro del workspace y que necesitan control de cambios sin recurrir a herramientas externas complejas.

Prerequisitos

Cuenta Azure con permisos para crear y modificar objetos en Azure Synapse Analytics.
Workspace Synapse con Dedicated SQL Pool (o base SQL dentro del workspace).
Conocimientos básicos de T-SQL y convenciones de nombrado.

Paso 1: Entender el porqué y elegir estrategia

Existen varias formas de versionar esquemas: migrations con CI/CD, herramientas externas o un patrón sencillo basado en el nombrado de objetos y tablas de metadatos. Aquí usamos un método práctico: crear una tabla de historial de esquemas y aplicar versiones con nombres que incluyen un número de versión. Esto permite rollback rápido y auditoría sin requerir pipelines externos.

Paso 2: Crear la tabla de metadatos de esquema

Crea una tabla donde registrarás cada cambio de esquema: objeto, versión, autor, fecha y script de cambio. Guardar el script permite reconstruir el estado anterior.

CREATE TABLE dbo.SchemaVersioning (
  ObjectName sysname NOT NULL,
  VersionNumber INT NOT NULL,
  AppliedBy sysname NOT NULL,
  AppliedAt DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(),
  ChangeScript NVARCHAR(MAX) NOT NULL,
  CONSTRAINT PK_SchemaVersioning PRIMARY KEY (ObjectName, VersionNumber)
);

Paso 3: Estandarizar nombres de tablas versionadas

Adopta una convención sencilla para tablas activas e históricas. Por ejemplo, tabla base mytable_v1; cuando modifiques el esquema crea mytable_v2 y después actualiza la view o sinónimo para apuntar a la versión activa.

-- ejemplo de nombrado
-- Tabla activa: Sales_v3
-- Tabla siguiente: Sales_v4

Paso 4: Exportar el DDL actual y crear nueva versión

Antes de cambiar, exporta el DDL actual (por ejemplo con SCRIPT TABLE en Synapse Studio o usando OBJECT_DEFINITION). A continuación, crea la nueva tabla con el nuevo DDL y copia datos si es necesario.

-- obtener DDL simplificado (ejemplo de captura del esquema de columnas)
SELECT c.name, t.name AS type_name, c.max_length, c.is_nullable
FROM sys.columns c
JOIN sys.types t ON c.user_type_id = t.user_type_id
WHERE object_id = OBJECT_ID('dbo.Sales_v3');

-- crear nueva versión (ejemplo mínimo)
CREATE TABLE dbo.Sales_v4 (
  SalesId INT NOT NULL,
  ProductId INT NOT NULL,
  Quantity INT NOT NULL,
  SaleDate DATETIME2 NOT NULL,
  Region NVARCHAR(50) NULL
);

-- copiar datos de la versión anterior (cuando compatible)
INSERT INTO dbo.Sales_v4 (SalesId, ProductId, Quantity, SaleDate)
SELECT SalesId, ProductId, Quantity, SaleDate FROM dbo.Sales_v3;

Paso 5: Registrar la versión en la tabla de metadatos

Guarda el script usado para crear o cambiar la nueva versión dentro de SchemaVersioning. Esto permite auditabilidad y rollback.

DECLARE @script NVARCHAR(MAX) = N'
CREATE TABLE dbo.Sales_v4 (
  SalesId INT NOT NULL,
  ProductId INT NOT NULL,
  Quantity INT NOT NULL,
  SaleDate DATETIME2 NOT NULL,
  Region NVARCHAR(50) NULL
);
';

INSERT INTO dbo.SchemaVersioning (ObjectName, VersionNumber, AppliedBy, ChangeScript)
VALUES ('dbo.Sales', 4, SUSER_SNAME(), @script);

Paso 6: Actualizar apuntador a la versión activa

En lugar de modificar aplicaciones, usa una view o un sinónimo que siempre apuntará a la versión activa. Cambiar el apuntador es una operación rápida y segura.

-- usar view para apuntado
IF OBJECT_ID('dbo.vw_Sales', 'V') IS NOT NULL
  DROP VIEW dbo.vw_Sales;

CREATE VIEW dbo.vw_Sales AS
SELECT * FROM dbo.Sales_v4;

Paso 7: Hacer rollback si es necesario

Si la nueva versión tiene problemas, recrea la view para apuntar a la versión anterior y registra un nuevo registro de rollback en SchemaVersioning. Para rollback completo, también puedes recrear la tabla anterior a partir del script guardado.

-- rollback simple: apuntar view a la versión anterior
ALTER VIEW dbo.vw_Sales AS
SELECT * FROM dbo.Sales_v3;

-- registrar rollback
INSERT INTO dbo.SchemaVersioning (ObjectName, VersionNumber, AppliedBy, ChangeScript)
VALUES ('dbo.Sales', 5, SUSER_SNAME(), 'Rollback to v3 via ALTER VIEW');

Verificar el resultado

Verifica que la view apunta a la tabla correcta y que la tabla de metadatos contiene registros para cada cambio. Prueba queries de lectura y, si procede, valida la integridad de los datos tras la copia.

-- confirmar apuntado de la view
SELECT OBJECT_NAME(OBJECT_ID) AS ViewName, definition
FROM sys.sql_modules m
JOIN sys.views v ON m.object_id = v.object_id
WHERE v.name = 'vw_Sales';

-- listar versiones
SELECT * FROM dbo.SchemaVersioning WHERE ObjectName = 'dbo.Sales' ORDER BY VersionNumber DESC;

Conclusión

Versionar esquemas directamente en Azure Synapse Analytics con una tabla de metadatos y convenciones de nombrado es una solución ligera y eficaz para control de cambios y rollback rápido. Próximos pasos: integrar este flujo con pipelines CI/CD o automatizar la creación de DDL a partir de plantillas. Consejo: prueba siempre el proceso de rollback en un entorno de stage antes de producción — ¿qué parte del proceso quieres automatizar primero?