Administração de Banco de Dados (PARTE XXIV)

ALTER TABLE e evolução estrutural dos bancos de dados

Nas partes anteriores desta série exploramos consultas, Views, e funções SQL. Até este momento, assumimos que a estrutura das tabelas já estava pronta e atendia perfeitamente às necessidades do sistema.

Quando estamos aprendendo, o cenário é sempre ideal: nós desenhamos as tabelas no papel, criamos o banco de dados e ele fica perfeito para sempre.

Mas no mundo real, o desenvolvimento de software é dinâmico. As regras de negócio mudam constantemente. E se a diretoria decidir que agora o sistema precisa armazenar o número de telefone do cliente? E se o limite de caracteres do campo de e-mail ficou muito pequeno? Como modificar uma tabela que já existe sem precisar apagá-la e recriá-la do zero?

É justamente para resolver esse problema que existe o comando ALTER TABLE. Neste artigo, aprenderemos como modificar estruturas já existentes, adicionar novas colunas, renomear elementos, alterar tipos de dados, remover campos desnecessários e compreender os impactos que essas alterações podem causar em sistemas reais.

Cenário de testes

Continuaremos utilizando a tabela clientes desenvolvida ao longo da série.

CREATE TABLE clientes ( 
    id_cliente INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, 
    nome VARCHAR(150) NOT NULL, 
    cpf CHAR(11) UNIQUE NOT NULL, 
    email VARCHAR(60) UNIQUE NOT NULL, 
    salario DECIMAL(10,2) NOT NULL, 
    data_cadastro DATE NOT NULL DEFAULT CURRENT_DATE, 
    CHECK(salario > 0) 
);

-- Comando para inserir dados nessa tabela clientes
INSERT INTO clientes (nome, cpf, email, salario)
VALUES
    ('Ana Souza', '99988877766', 'ana@email.com', 4200.00),
    ('Pedro Lima', '44455566677', 'pedro@email.com', 6100.00),
    ('Fernanda Costa', '33322211100', 'fernanda@email.com', 5300.00),
    ('Carlos Mendes', '77788899900', 'carlos@email.com', 3900.00),
    ('Marta Rodrigues', '12588899600', 'marta@email.com', 3500.00);

Imagine que essa tabela já está em produção e possui milhares de registros cadastrados e que agora surge uma nova necessidade de negócio: o setor comercial solicita que o sistema passe a armazenar também o telefone dos clientes. É nesse momento que entra em cena o comando ALTER TABLE.

O Comando ALTER TABLE

O comando ALTER TABLE é a ferramenta definitiva para a evolução estrutural. Ele permite adicionar, remover ou modificar colunas, alterar restrições (constraints) e renomear objetos sem a necessidade de apagar os dados que já estão armazenados. Diferentemente dos comandos INSERT, UPDATE e DELETE, que manipulam os dados armazenados, o ALTER TABLE modifica a própria definição da tabela.

Com ele podemos:

• adicionar colunas;
• remover colunas;
• alterar tipos de dados;
• renomear tabelas;
• renomear colunas;
• criar ou remover restrições;
• modificar propriedades estruturais.

Sua sintaxe básica é:

ALTER TABLE nome_tabela
acao_desejada;

Onde:

• ALTER TABLE: indica que uma tabela existente será modificada;
• nome_da_tabela: tabela que sofrerá a alteração;
• ação_desejada: operação que será realizada sobre a estrutura da tabela.

💡 Observação importante Embora o comando ALTER TABLE preserve os dados existentes na maioria das alterações, algumas operações podem afetar informações já armazenadas ou exigir que os registros atendam a determinadas condições. Por esse motivo, alterações estruturais devem ser planejadas e testadas cuidadosamente antes de serem aplicadas em ambientes de produção.

Para os nossos testes, vamos utilizar nossa tabela clientes, definida e populada no cenário de testes. A partir de agora, vamos acompanhar como essa tabela pode evoluir diante das demandas de uma empresa. Entre as operações mais comuns realizadas através desse comando serão descritas a seguir.

Adicionando novas colunas com ADD COLUMN

À medida que um sistema evolui, é comum que novas informações precisem ser armazenadas no banco de dados. Uma empresa pode decidir registrar o telefone dos clientes, adicionar um campo para data de nascimento ou incluir uma coluna para armazenar qualquer outro dado que favoreça as regras de negócio definidas em um momento determinado.

Nessas situações, não é necessário recriar a tabela ou perder os dados já existentes. A linguagem SQL disponibiliza o comando ADD COLUMN, que permite adicionar novas colunas a uma tabela de forma simples e segura, preservando todos os registros já armazenados.

Sua sintaxe básica é apresentada a seguir:

ALTER TABLE nome_da_tabela
ADD COLUMN nome_da_coluna tipo_de_dado;

Onde:

• ALTER TABLE: indica que a estrutura de uma tabela será modificada;
• ADD COLUMN: especifica que uma nova coluna será adicionada;
• nome_da_coluna: nome do novo campo;
• tipo_de_dado: tipo de informação que será armazenada.

Suponhamos que o setor de marketing da empresa solicitou que agora o sistema passe a capturar o telefone de contato dos clientes para o envio de mensagens. Essa ação pode ser realizada executando a seguinte instrução:

ALTER TABLE clientes 
ADD COLUMN telefone VARCHAR(15) UNIQUE;

O que acontecerá na prática será que o SGBD adicionará a nova coluna à definição da tabela, tornando-a disponível para todos os registros existentes. Para os clientes que já estavam cadastrados, o banco de dados preencherá essa nova coluna automaticamente com o valor NULL (afinal, não sabemos o telefone deles ainda) a menos que um valor padrão seja especificado durante a criação da coluna.

💡 Ponto de atenção: Se você tentar adicionar uma nova coluna com a restrição NOT NULL em uma tabela que já possui registros, o banco de dados retornará um erro. Para fazer isso de forma segura, você deve adicionar a coluna, fazer um UPDATE preenchendo os dados de todo mundo, e só depois alterar a estrutura para exigir o NOT NULL.

Também é possível adicionar mais de uma coluna na mesma operação, como mostrado no exemplo a seguir.

ALTER TABLE clientes
ADD COLUMN cidade VARCHAR(100),
ADD COLUMN estado CHAR(2);

Se você executar essa instrução, serão adicionadas essas colunas à direita de todas as outras na tabela clientes. Isso reduz a quantidade de comandos necessários durante alterações maiores.

Renomeando colunas com RENAME COLUMN

Durante o desenvolvimento de um sistema, é comum que determinados nomes de colunas deixem de representar adequadamente as informações que armazenam. Em outros casos, erros de nomenclatura podem passar despercebidos durante a criação da tabela, tornando necessária uma correção posterior.

Para lidar com essas situações, a linguagem SQL disponibiliza o comando RENAME COLUMN, que permite alterar o nome de uma coluna existente sem modificar os dados armazenados nela. Dessa forma, podemos tornar a estrutura do banco de dados mais clara, organizada e alinhada às regras de negócio da aplicação sem a necessidade de recriar colunas ou migrar dados.

Sua sintaxe básica é apresentada a seguir:

ALTER TABLE nome_da_tabela
RENAME COLUMN nome_antigo 
TO nome_novo;

Onde:

• ALTER TABLE: indica que a estrutura da tabela será modificada;
• RENAME COLUMN: especifica que uma coluna será renomeada;
• nome_antigo: nome atual da coluna;
• nome_novo: novo nome que será atribuído à coluna.

Por exemplo, imagine que um tempo depois, a equipe de desenvolvimento percebe que o nome “telefone” é muito genérico, pois o sistema só aceita números de celulares. Para manter o código limpo e sem ambiguidades, precisamos renomear a coluna. Para fazer isso, executamos a seguinte instrução:

ALTER TABLE clientes 
RENAME COLUMN telefone TO celular;

Desta forma, a estrutura da tabela foi atualizada instantaneamente. Da mesma forma, se a empresa passasse por um rebranding e quiséssemos renomear a própria tabela (por exemplo, de clientes para usuarios), usaríamos a sintaxe básica:

ALTER TABLE nome_antigo
RENAME TO novo_nome;

Se quisermos aplicar essa sintaxe na tabela clientes, teríamos que executar a seguinte instrução:

ALTER TABLE clientes RENAME TO usuarios;

Como resultado, a tabela clientes passaria a se chamar usuarios.

💡 Observação importante Ao renomear uma coluna, os dados armazenados não são alterados. Entretanto, consultas, Views, procedures, funções e aplicações que utilizam o nome antigo da coluna poderão precisar ser atualizadas para refletir a nova nomenclatura.

Alterando tipos de dados com ALTER COLUMN

À medida que um sistema evolui, pode surgir a necessidade de alterar a forma como determinadas informações são armazenadas. Uma coluna criada inicialmente para armazenar nomes curtos pode precisar suportar textos maiores, ou um campo que armazenava números inteiros pode passar a exigir valores decimais.

Nesses casos, não é necessário remover a coluna e criá-la novamente. O SQL disponibiliza o comando ALTER COLUMN, que permite modificar características de uma coluna existente, incluindo seu tipo de dado. Dessa forma, podemos adaptar a estrutura do banco de dados às novas necessidades da aplicação sem perder as informações já armazenadas e sem a necessidade de recriar tabelas.

Sua sintaxe básica é apresentada a seguir:

ALTER TABLE nome_da_tabela
ALTER COLUMN nome_da_coluna
TYPE novo_tipo;

Onde:

• ALTER TABLE: indica que a estrutura da tabela será modificada;
• ALTER COLUMN: especifica a coluna que será alterada;
• TYPE: informa que o tipo de dado será modificado;
• novo_tipo: novo tipo de dado que a coluna passará a utilizar.

Agora imagine que a nossa aplicação foi expandida internacionalmente. Agora, precisamos aceitar códigos de país (como o +55 do Brasil) no campo de celular, e o nosso VARCHAR(15) ficou pequeno para suportar os novos formatos de digitação. Neste caso precisamos aumentar o limite para VARCHAR(20), o qual pode ser realizado através da seguinte instrução:

ALTER TABLE clientes 
ALTER COLUMN celular TYPE VARCHAR(20);

Como resultado, o banco de dados processará essa alteração ampliando a capacidade de armazenamento da coluna sem apagar os números que já estavam lá dentro.

💡 Observação importante Nem toda conversão entre tipos de dados é possível. Para que a alteração seja realizada com sucesso, os valores já armazenados na coluna precisam ser compatíveis com o novo tipo definido.

Alterando restrições de dados com ADD CONSTRAINT

Ao criar uma tabela, nem sempre conseguimos definir todas as regras que os dados deverão seguir ao longo da vida do sistema. À medida que a aplicação evolui, novas necessidades surgem e pode ser necessário reforçar a integridade das informações armazenadas no banco de dados.

Para atender a essas situações, o SQL disponibiliza o comando ADD CONSTRAINT, que permite adicionar restrições a tabelas já existentes. Dessa forma, podemos estabelecer novas regras de validação sem precisar recriar a estrutura da tabela ou perder os dados já cadastrados.

Sua sintaxe básica é apresentada a seguir:

ALTER TABLE nome_da_tabela
ADD CONSTRAINT nome_da_constraint
tipo_da_constraint;

Onde:

• ALTER TABLE: indica que a estrutura da tabela será modificada;
• ADD CONSTRAINT: especifica que uma nova restrição será adicionada;
• nome_da_constraint: nome atribuído à restrição;
• tipo_da_constraint: regra que será aplicada aos dados.

Entre as restrições mais frequentemente adicionadas por meio desse comando estão:

• PRIMARY KEY: identifica unicamente cada registro da tabela;
• FOREIGN KEY: estabelece relacionamentos entre tabelas;
• UNIQUE: impede valores duplicados;
• CHECK: valida regras específicas definidas pelo usuário.

Suponha que na tabela clientes desejamos impedir que dois clientes possuam o mesmo telefone cadastrado. Essa restrição poderia ser adicionada executando a seguinte instrução:

ALTER TABLE clientes
ADD CONSTRAINT uq_clientes_telefone
UNIQUE(telefone);

Após a criação da constraint, o banco impedirá a inserção de números telefônicos duplicados.

Agora imagine que não tenhamos nenhuma restrição definida na coluna salario e desejamos garantir que esse valor cadastrado seja sempre maior que zero. Essa restrição poderia ser implementada executando a seguinte instrução:

ALTER TABLE clientes
ADD CONSTRAINT chk_salario
CHECK (salario > 0);

Nesse caso, qualquer tentativa de inserir ou atualizar um salário com valor igual ou inferior a zero será rejeitada pelo banco de dados.

O comando também pode ser utilizado para criar relacionamentos entre tabelas da seguinte forma:

ALTER TABLE pedidos
ADD CONSTRAINT fk_pedidos_id_cliente
FOREIGN KEY (id_cliente)
REFERENCES clientes(id_cliente);

A partir desse momento, cada pedido deverá estar associado a um cliente existente na tabela clientes.

💡 Observação importante Antes de adicionar uma constraint, o banco de dados verifica os registros já existentes na tabela. Caso algum deles viole a nova regra, a criação da restrição será interrompida e uma mensagem de erro será exibida no console.

Alterando Defaults e Constraints

A estrutura de uma tabela não é composta apenas por colunas e tipos de dados. Em muitos casos, também definimos valores padrão (defaults) e restrições (constraints) para garantir a integridade e a consistência das informações armazenadas.

Entretanto, conforme as regras de negócio evoluem, pode ser necessário alterar essas configurações. Uma empresa pode decidir que novos clientes devem ser cadastrados como ativos por padrão, ou pode surgir a necessidade de tornar um campo obrigatório que antes era opcional.

Para realizar esse tipo de ajuste, o SQL disponibiliza comandos que permitem modificar valores padrão e restrições já existentes, adaptando a estrutura da tabela sem a necessidade de recriá-la.

1. Alterando valores padrão (DEFAULT)

Os valores padrão são utilizados para preencher automaticamente uma coluna quando nenhum valor é informado durante uma inserção. Caso seja necessário alterar esse comportamento, podemos modificar a configuração da coluna utilizando o comando ALTER COLUMN. Sendo assim, podemos modificar valores DEFAULT usando a sintaxe básica:

ALTER TABLE nome_da_tabela
ALTER COLUMN nome_da_coluna
SET DEFAULT valor;

Por exemplo, suponhamos que, após já termos alterado o tipo da coluna data_cadastro para TIMESTAMP, desejamos que seu preenchimento automático passe a utilizar o valor CURRENT_TIMESTAMP (data e hora exata), em vez da CURRENT_DATE (apenas a data), que havia sido definida no momento em que criamos a tabela. Essa alteração do valor padrão pode ser realizada executando a seguinte instrução:

ALTER TABLE clientes
ALTER COLUMN data_cadastro
SET DEFAULT CURRENT_TIMESTAMP;

O resultado será que, ao invés de armazenar o valor de data_cadastro como CURRENT_DATE, passará a utilizar CURRENT_TIMESTAMP como valor padrão. Como a coluna data_cadastro foi definida como DATE, a informação de horário poderá ser descartada. Para armazenar data e hora, a coluna deveria utilizar CURRENT_TIMESTAMP como valor padrão.

Também é possível remover o valor padrão da seguinte forma:

ALTER TABLE clientes
ALTER COLUMN data_cadastro
DROP DEFAULT;

2. Alterando constraints

As constraints são regras responsáveis por garantir a integridade dos dados armazenados. Elas podem exigir que determinados campos sejam preenchidos, impedir valores duplicados ou garantir relacionamentos entre tabelas. Uma das alterações mais comuns é tornar uma coluna obrigatória utilizando a constraint NOT NULL.

Por exemplo, suponha que a coluna celular contém preenchidos todos os números de celular de cada cliente, mas agora desejamos exigir seu preenchimento no momento de realizar um novo cadastro. Isso pode ser realizado executando a seguinte instrução:

ALTER TABLE clientes
ALTER COLUMN celular
SET NOT NULL;

Após essa alteração, novos registros não poderão ser inseridos sem informar um número de celular.

Também é possível remover essa exigência executando a seguinte instrução:

ALTER TABLE clientes
ALTER COLUMN email
DROP NOT NULL;

Nesse caso, a coluna voltará a aceitar valores nulos.

💡 Observação importante Antes de adicionar uma constraint, é importante verificar se os dados já armazenados atendem à nova regra. Caso contrário, o banco de dados poderá impedir a alteração.

Removendo colunas com DROP COLUMN

Durante a evolução de um sistema, é comum que determinadas informações deixem de ser necessárias. Uma coluna pode ter sido criada para atender a uma regra de negócio que não existe mais, ou talvez tenha sido substituída por outra estrutura mais adequada.

Nesses casos, manter campos desnecessários na tabela pode dificultar a manutenção do banco de dados e tornar sua estrutura mais complexa do que o necessário. Para resolver esse problema, a linguagem SQL disponibiliza o comando DROP COLUMN, que permite remover colunas existentes de uma tabela. O comando DROP COLUMN é amplamente utilizado durante processos de manutenção e refatoração de bancos de dados.

Sua sintaxe básica é apresentada a seguir:

ALTER TABLE nome_da_tabela
DROP COLUMN nome_da_coluna;

Onde:

• ALTER TABLE: indica que a estrutura da tabela será modificada;
• DROP COLUMN: especifica que uma coluna será removida;
• nome_da_coluna: coluna que será excluída da tabela.

Imagine que para cumprir a Lei Geral de Proteção de Dados (LGPD), o departamento jurídico da empresa ordenou que o sistema pare imediatamente de armazenar o número de celular dos clientes, pois é um dado sensível que não tem mais utilidade para o negócio atual.

Para realizar essa operação, precisamos remover a coluna celular da seguinte forma:

ALTER TABLE clientes 
DROP COLUMN celular;

Como resultado da execução desse comando, quando fizer uma consulta SELECT FROM clientes**; não aparecerá mais a coluna celular, pois ela foi apagada totalmente da tabela clientes*** e as consultas que utilizavam essa coluna deixarão de funcionar.

💡 Observação importante Ao remover uma coluna, todos os dados armazenados nela são perdidos permanentemente. Por esse motivo, é recomendável verificar cuidadosamente se a informação realmente não será mais necessária antes de executar o comando. Alguns SGBDs impedem a remoção de colunas que estejam sendo utilizadas por constraints, índices, views ou chaves estrangeiras, exigindo a remoção prévia dessas dependências.

O Impacto estrutural das alterações e os riscos no ambiente de produção

Modificar a estrutura de uma tabela com o ALTER TABLE parece algo simples olhando de fora, mas em um ambiente de produção real (sistemas rodando 24 horas por dia), essa operação é temida e exige muito planejamento.

Existem três impactos profundos que você precisa considerar antes de rodar esse comando:

1. Table Locks (Travamento da Tabela): Dependendo do SGBD e do tipo de alteração (como reescrever o tipo de dado de uma coluna), o banco de dados precisará “trancar” a tabela inteira enquanto aplica a mudança estrutural. Se a tabela tiver milhões de registros, esse processo pode levar minutos ou até horas. Durante esse tempo, nenhum usuário da sua aplicação conseguirá fazer login, compras ou consultas. O sistema parecerá “fora do ar”. É por isso que DBAs executam essas manutenções de madrugada.
2. A quebra do SELECT *:* Se a sua aplicação utiliza a má prática do SELECT * FROM clientes***, adicionar uma nova coluna pode quebrar aplicações que dependam da ordem ou quantidade exata de colunas retornadas, pois o backend passará a receber uma variável a mais (ex: celular) que ele não estava esperando em seu código.
3. Efeito cascata em Views e Procedures: Como vimos nos artigos anteriores, criamos Views que dependem diretamente da tabela clientes (como a View de faturamento que usava o salario). Se rodarmos um DROP COLUMN salario, todas as Views e outros objetos do banco de dados que dependam dessa coluna vão quebrar (ficarão em estado inválido).

Boas práticas ao utilizar ALTER TABLE

Antes de modificar estruturas em ambientes corporativos, recomenda-se:

1. Fazer backup: Sempre mantenha uma cópia atualizada dos dados antes de alterações importantes.

2. Testar em ambiente de homologação: Nunca execute mudanças diretamente em produção sem testes prévios.

3. Avaliar dependências: Sempre que possível, verifique:

• Views;
• Procedures;
• Functions;
• Triggers;
• Relatórios;
• Aplicações.

Todos esses elementos podem depender da estrutura que será alterada.

4. Documentar alterações: Mudanças estruturais devem ser registradas para facilitar futuras manutenções.

Quando utilizar ALTER TABLE?

O comando ALTER TABLE é indicado quando precisamos:

• adaptar tabelas a novos requisitos;
• corrigir problemas de modelagem;
• aumentar capacidade de armazenamento;
• remover estruturas obsoletas;
• melhorar a organização do banco de dados.

Ele é uma das ferramentas mais importantes da administração e manutenção de bancos de dados relacionais.

Considerações finais

Durante o desenvolvimento de sistemas, as necessidades de negócio mudam constantemente. Por esse motivo, a estrutura de um banco de dados dificilmente permanece inalterada ao longo do tempo.

O comando ALTER TABLE fornece os mecanismos necessários para adaptar tabelas já existentes sem a necessidade de recriá-las do zero, permitindo adicionar colunas, modificar tipos de dados, renomear elementos e remover estruturas obsoletas.

Contudo, toda alteração estrutural deve ser realizada com planejamento e cautela, pois uma simples modificação pode impactar aplicações inteiras, relatórios, integrações e usuários finais.

Dominar o ALTER TABLE é um passo fundamental para qualquer desenvolvedor SQL, analista de dados ou DBA que deseje trabalhar com manutenção e evolução de sistemas em ambientes reais.

Mas existe um novo desafio. Até agora modificamos tabelas manualmente, executando comandos sempre que desejávamos alterar a estrutura do banco de dados. Em projetos profissionais, entretanto, essas mudanças precisam ser controladas, versionadas e reproduzidas automaticamente entre diferentes ambientes.

Na próxima parte da nossa série estudaremos DROP TABLE, DROP DATABASE, TRUNCATE, DELETE, suas diferenças, riscos e formas de fazer backups do banco de dados de forma segura, organizada e profissional.

Gostou desse resumo prático? Não esqueça de deixar suas palmas 👏, considere compartilhá-lo com outras pessoas que também estejam aprendendo banco de dados, deixe seus comentários se tiver alguma dúvida sobre os conceitos apresentados e continue acompanhando a série.

Desde o mais profundo do meu coração, espero que este conteúdo tenha contribuído para aprofundar seus conhecimentos sobre SQL e bancos de dados relacionais.

Nos vemos na próxima parte!

Para continuar lendo a matéria, ***clique neste link***.

Referências bibliográficas consultadas

ALVES, William Pereira. Banco de Dados — Teoria e Desenvolvimento. São Paulo: Editora Érica, 2009. DATE, C. J. Introdução aos Sistemas de Banco de Dados. 8. ed. Rio de Janeiro: Campus, 2004. ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados. São Paulo: Pearson/Addison Wesley, 2011. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de Dados. São Paulo: Elsevier, 2012.