O que acontece quando você define a estrutura de um banco de dados
A criação de tabelas campos e regras é classificada como DDL, sigla para Data Definition Language, ou Linguagem de Definição de Dados. Faz parte do SQL padrão e engloba os comandos que estruturam o banco, não os dados em si.
criação de tabelas campos e regras é classificada como
DDL é um subconjunto do SQL dedicado à definição de esquemas. Os comandos principais são CREATE, ALTER, DROP, TRUNCATE e RENAME. Cada um deles opera na estrutura: tabelas, colunas, tipos, restrições, índices e esquemas. O banco de dados processa esses comandos de forma diferente dos DMLs, porque não se trata de ler ou escrever registros, mas de modificar o catálogo do sistema. No dia a dia, eu costumo usar DDL para montar a base e depois preencher com INSERTs e UPDATEs. Só que a transição entre uma e outra coisa é mais sutil do que parece.
Comandos práticos que você vai usar
Veja um exemplo real do que eu executo em projetos pequenos e médios: CREATE TABLE clientes (
id INT PRIMARY KEY AUTO_INCREMENT,
nome VARCHAR(150) NOT NULL,
cpf VARCHAR(14) UNIQUE,
email VARCHAR(255),
data_cadastro TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
Nesse comando, cada linha faz parte do DDL. O PRIMARY KEY, o NOT NULL e o UNIQUE são regras (restrições) definidas junto com os campos. O DEFAULT também é definido no nível da estrutura. Para alterar a tabela depois, eu uso:
ALTER TABLE clientes ADD COLUMN telefone VARCHAR(20);
ALTER TABLE clientes ADD CONSTRAINT uk_telefone UNIQUE (telefone); Para remover, o DROP TABLE clientes apaga tudo. O TRUNCATE TABLE clientes mantém a estrutura mas zera os registros, e costuma ser mais rápido porque não gera log por linha.
O que a maioria das pessoas não explica sobre DDL
DDL não é neutro em relação ao comportamento do banco. Dependendo do SGBD, ele pode travar tabelas inteiras durante a execução. No PostgreSQL, um ALTER TABLE pode adquirir um lock ShareLock ou RowExclusiveLock dependendo da operação. No MySQL, versões mais antigas faziam cópia completa da tabela em alguns casos de ALTER, o que podia levar horas em tabelas grandes. Outra coisa que muitos esquecem: DDL é implícito. A menos que você explicitamente envolva em uma transação, o comando é autocommit. Isso significa que erros parciais podem gerar estrutura inconsistente se o banco não suportar rollback de DDL, como acontece em alguns cenários do Oracle antigo.
👉 Clique no botão abaixo para saber mais sobre o assunto!
No SQL Server, comandos como DROP e ALTER também geram registro em log, mas o nível de detalhe varia conforme o modelo de recuperação. Se você estiver em modo FULL, cada DDL pode encher o log rapidamente. Em SIMPLE, o log é truncado automaticamente, mas a operação ainda ocupa espaço temporário.
Um problema real que eu encontrei e como resolvi
Em um projeto com tabelas de pedidos com mais de 40 milhões de linhas, precisei adicionar uma coluna nova com valor padrão. O ALTER TABLE simples travou a sessão por mais de 20 minutos e quase derrubou a aplicação porque o MySQL 5.7 fazia cópia completa da tabela antes de aplicar a modificação. A solução foi usar a abordagem online do InnoDB com ALTER TABLE ... ALGORITHM=INPLACE, CHANGE COLUMN, mas mesmo assim eu executei o comando em horário de baixo tráfego e monitorei o processamento com INFORMATION_SCHEMA.INNODB_TRX. Quando a tabela tinha partições, eu apliquei a alteração em uma partição de teste primeiro para verificar o tempo real antes de rodar em produção.
Se o banco for PostgreSQL, o comportamento é diferente: a maioria dos ALTER TABLE é rápida porque o PostgreSQL modifica o catálogo e só exige locks mais fortes em operações específicas, como mudança de tipo de coluna. O comando ALTER TABLE ... ADD COLUMN com DEFAULT funciona quase instantaneamente porque o valor padrão é aplicado na leitura, não reescrito em cada linha.
Pegadas comuns que iniciantes cometem
O primeiro erro frequente é confundir DDL com DML. INSERT, UPDATE, DELETE e SELECT fazem parte do DML, não do DDL. Usar DDL pensando que está manipulando dados só gera confusão na hora de debugar erros de permissão. O segundo erro é criar tabelas sem definir constraints de forma adequada. Colunas nullable sem regra, chaves estrangeiras sem, e nomes de colunas que conflitam com palavras reservadas são problemas que aparecem depois, quando o banco já está populado.
O terceiro erro é rodar DROP sem verificar dependências. Tabelas vinculadas a views, stored procedures ou triggers podem quebrar silenciosamente se você não consultar o catálogo de dependências do SGBD antes de executar.
Quando DDL não é a melhor ferramenta
Se o objetivo é apenas transformar dados dentro de tabelas existentes, use DML. Se precisa migrar esquemas em massa, ferramentas como migrations de ORM ou scripts versionados funcionam melhor do que DDL puro feito manualmente. DDL também não é ideal para operações frequentes em ambientes de alta concorrência, porque cada modificação de estrutura concorre com transações ativas. Nestes casos, o recomendado é usar técnicas de DDL online quando disponíveis, ou fazer janelas de manutenção com réplicas em leitura.
Resumo direto
A criação de tabelas, campos e regras pertence ao conjunto DDL do SQL. O comando CREATE constrói a estrutura, ALTER a modifica, DROP a remove, e TRUNCATE zera o conteúdo mantendo o esquema. Cada SGBD tem particularidades de lock e performance que devem ser conhecidas antes de executar esses comandos em produção. DDL é poderoso, mas exige consciência de impacto. Errar a ordem das operações ou ignorar o modelo de recuperação do banco pode transformar uma modificação simples em uma madrugada debugging lock timeout.
