⌘K

02 – SQL no PostgreSQL: Dominando o Comando CREATE TABLE e Boas Práticas

Last updated

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ão NomeUsuario ou nomeUsuario). 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 TEXT ou VARCHAR(255) para tudo. Se um campo armazena uma sigla de estado com 2 letras, use CHAR(2).
  • Para IDs únicos globais, avalie o uso de UUID em vez de SERIAL. O UUID evita 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!

Still stuck? How can we help? Get Help