No nosso último post, vimos que o SQL é a linguagem universal para lidar com bancos de dados relacionais. Hoje, vamos dar o primeiro passo prático na construção de uma base de dados: como criar tabelas de forma eficiente.
O comando CREATE TABLE parece simples à primeira vista, mas quando pensamos em ambientes de produção, performance e cultura DevOps, a forma como desenhamos nossas tabelas dita o sucesso (ou o fracasso) da aplicação.
Vamos entender a sintaxe, ver exemplos práticos no PostgreSQL e listar as melhores práticas de mercado.
A Sintaxe Básica
Para criar uma tabela, precisamos definir o seu nome, o nome das colunas, os tipos de dados que cada coluna vai aceitar e as restrições (constraints) de integridade.
CREATE TABLE nome_da_tabela (
coluna1 tipo_de_dado restricao,
coluna2 tipo_de_dado,
coluna3 tipo_de_dado
);
Exemplo Prático: Cenário DevOps / Dados
Imagine que precisamos monitorar o deploy de aplicações em clusters Kubernetes. Vamos criar uma tabela chamada deploys para registrar essas informações.
CREATE TABLE deploys (
id SERIAL PRIMARY KEY,
nome_app VARCHAR(100) NOT NULL,
ambiente VARCHAR(20) NOT NULL CHECK (ambiente IN ('dev', 'staging', 'prod')),
versao_tag VARCHAR(30) NOT NULL,
quantidade_replicas INT DEFAULT 1,
criado_em TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);
O que está acontecendo aqui?
SERIAL PRIMARY KEY: O Postgres cria automaticamente uma sequência numérica auto-incrementável para identificar exclusivamente cada linha.VARCHAR(100) NOT NULL: Define uma string de até 100 caracteres que obrigatoriamente precisa ser preenchida.CHECK (ambiente IN (...)): Uma restrição de validação. O Postgres vai rejeitar qualquer tentativa de insert se o ambiente não for um dos três especificados.DEFAULT 1: Se não informarmos a quantidade de réplicas no insert, o banco assume o valor 1.TIMESTAMP WITH TIME ZONE: Armazena data e hora incluindo o fuso horário. Isso é crucial para infraestrutura distribuída.
Boas Práticas no mundo real
Se você gerencia bancos de dados ou automatiza infraestrutura, adote esses hábitos desde o primeiro dia:
1. Padronize a Nomenclatura (Naming Conventions)
- Use snake_case: Tabelas e colunas devem ser escritas em minúsculo, separadas por underline (
nome_usuario, e nãoNomeUsuarioounomeUsuario). O Postgres converte tudo para minúsculo por padrão se você não usar aspas, então evite dores de cabeça. - Apenas no plural ou apenas no singular: Defina um padrão para o nome das tabelas (ex:
usuarios,servidores,logs) e mantenha-o em todo o projeto.
2. Atenção Total ao fuso horário (Timezones)
Sempre que salvar datas de criação ou modificação (created_at/updated_at), use TIMESTAMP WITH TIME ZONE (ou TIMESTAMPTZ). Em ambientes Cloud e DevOps, onde os servidores podem estar em regiões diferentes (AWS us-east-1, sa-east-1), padronizar os registros em UTC direto no banco evita erros bizarros de auditoria.
3. Escolha os Tipos de Dados Corretos
- Não use
TEXTouVARCHAR(255)para tudo. Se um campo armazena uma sigla de estado com 2 letras, useCHAR(2). - Para IDs únicos globais, avalie o uso de
UUIDem vez deSERIAL. OUUIDevita previsibilidade de dados e facilita a replicação entre múltiplos bancos.
4. Use Índices com Sabedoria
Campos que serão muito utilizados em filtros (WHERE) ou junções (JOIN) devem ser indexados para garantir performance quando a tabela crescer. (Nota: Chaves primárias – PRIMARY KEY – ganham um índice automaticamente).
Conclusão
Criar uma tabela vai muito além de apenas listar colunas. É sobre garantir a consistência dos dados antes mesmo da aplicação tentar salvá-los. No PostgreSQL, a riqueza de tipos de dados e restrições permite blindar sua arquitetura contra dados corrompidos ou mal formatados.
No próximo post, vamos avançar um passo e entender como o comando ALTER TABLE funciona e como gerenciar alterações de esquema (migrations) sem derrubar o ambiente de produção.
Você já teve problemas em produção por causa de um tipo de dado mal escolhido? Compartilhe sua experiência aqui nos comentários!