Como versionar esquemas de tabelas no Azure Synapse Analytics: passo a passo

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

Este tutorial explica como implementar um método simples para versionar esquemas de tabelas em Azure Synapse Analytics, de forma a manter um histórico e a facilitar rollbacks. A abordagem é útil para equipas que alteram tabelas em Dedicated SQL Pool ou em bases SQL dentro do workspace e que precisam de controlo de alterações sem recorrer a ferramentas externas complexas.

Pré-requisitos

Conta Azure com permissões para criar e alterar objectos no Azure Synapse Analytics.
Workspace Synapse com Dedicated SQL Pool (ou base SQL dentro do workspace).
Conhecimentos básicos de T-SQL e convenções de nomeação.

Passo 1: Entender o porquê e escolher estratégia

Existem várias formas de versionar esquemas: migrations com CI/CD, ferramentas externas ou um padrão simples baseado em nomeação de objectos e tabelas de metadados. Aqui usamos um método prático: criar uma tabela de histórico de esquemas e aplicar versões com nomes que incluem um número de versão. Isto permite rollback rápido e auditoria sem requerer pipelines externos.

Passo 2: Criar a tabela de metadados de esquema

Cria uma tabela onde irás registar cada alteração de esquema: objecto, versão, autor, data e script de alteração. Guardar o script permite reconstruir o 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)
);

Passo 3: Padronizar nomes de tabelas versionadas

Adopta uma convenção simples para tabelas activas e históricas. Por exemplo, tabela base mytable_v1; quando alterares o esquema cria mytable_v2 e depois actualiza a view ou sinónimo para apontar para a versão activa.

-- exemplo de nomeação
-- Tabela activa: Sales_v3
-- Tabela seguinte: Sales_v4

Passo 4: Exportar o DDL actual e criar nova versão

Antes de alterar, exporta o DDL actual (por exemplo com SCRIPT TABLE no Synapse Studio ou usando OBJECT_DEFINITION). Em seguida, cria a nova tabela com o novo DDL e copia dados se necessário.

-- obter DDL simplificado (exemplo de captura do esquema de colunas)
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');

-- criar nova versão (exemplo 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 dados da versão anterior (quando compatível)
INSERT INTO dbo.Sales_v4 (SalesId, ProductId, Quantity, SaleDate)
SELECT SalesId, ProductId, Quantity, SaleDate FROM dbo.Sales_v3;

Passo 5: Registar a versão na tabela de metadados

Guarda o script usado para criar ou alterar a nova versão dentro de SchemaVersioning. Isto permite auditabilidade e 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);

Passo 6: Actualizar apontamento para a versão activa

Em vez de alterar aplicações, usa uma view ou um sinónimo que sempre apontará para a versão activa. Alterar o apontamento é uma operação rápida e segura.

-- usar view para apontamento
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;

Passo 7: Fazer rollback se necessário

Se a nova versão tiver problemas, recria a view para apontar para a versão anterior e regista um novo registo de rollback em SchemaVersioning. Para rollback completo, podes também recriar a tabela anterior a partir do script guardado.

-- rollback simples: apontar view para versão anterior
ALTER VIEW dbo.vw_Sales AS
SELECT * FROM dbo.Sales_v3;

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

Verificar o resultado

Verifica que a view aponta para a tabela correcta e que a tabela de metadados contém registos para cada alteração. Testa queries de leitura e, se aplicável, valida a integridade dos dados após a cópia.

-- confirmar apontamento da 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 versões
SELECT * FROM dbo.SchemaVersioning WHERE ObjectName = 'dbo.Sales' ORDER BY VersionNumber DESC;

Conclusão

Versionar esquemas directamente em Azure Synapse Analytics com uma tabela de metadados e convenções de nomeação é uma solução leve e eficaz para controlo de alterações e rollback rápido. Próximos passos: integrar este fluxo com pipelines CI/CD ou automatizar a criação de DDL a partir de templates. Dica: testa sempre o processo de rollback num ambiente de stage antes de produção — que parte do processo queres automatizar primeiro?