Exemplos práticos de base de dados relacional
Aqui estão alguns exemplos funcionais de esquemas de banco de dados que eu vejo sendo implementados com frequência, tanto em projetos pequenos quanto em sistemas maiores. Vou direto ao ponto.
Base de dados exemplos para e-commerce simples
Esse é um dos mais comuns. Uma estrutura básica com três tabelas principais: produtos(id SERIAL PRIMARY KEY, nome VARCHAR(255) NOT NULL, descricao TEXT, preco DECIMAL(10,2) NOT NULL, estoque INTEGER DEFAULT 0, criado_em TIMESTAMP DEFAULT CURRENT_TIMESTAMP)
clientes(id SERIAL PRIMARY KEY, nome VARCHAR(255) NOT NULL, email VARCHAR(255) UNIQUE NOT NULL, telefone VARCHAR(20), endereco TEXT, criado_em TIMESTAMP DEFAULT CURRENT_TIMESTAMP) pedidos(id SERIAL PRIMARY KEY, cliente_id INTEGER REFERENCES clientes(id), data_hora TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total DECIMAL(12,2), status VARCHAR(50) DEFAULT 'pendente')
Isso cobre o essencial. Na prática, você vai precisar de uma tabela de itens_do_pedido para separar os produtos de cada compra. Sem essa separação, não há como rastrear quais produtos exatos foram comprados, especialmente se o preço ou a descrição mudarem depois.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Base de dados exemplos para sistema de gestão escolar
Uma variante interessante que encontrei em um projeto real tinha alunos, turmas e professores como entidades centrais, com relacionamento muitos-para-muitos entre alunos e turmas. A complicação que ninguém menciona nos tutoriais é a questão das turmas com horários sobrepostos. Um aluno pode estar inscrito em duas turmas que acontecem no mesmo período. Você precisa de uma validação na aplicação, não no banco, porque o SQL puro não consegue impedir isso sem triggers complexos que vão te dar dor de cabeça depois. o que funciona bem aqui é normalizar até certo ponto e deixar a lógica de negócio na camada de aplicação. Tentar impor restrições de integridade exclusivamente no banco de dados nesse caso só gera manutenção desnecessária.
Exemplos comuns de base de dados que você deve conhecer
Além dos esquemas prontos, existem padrões recorrentes que aparecem em praticamente todo projeto. Índices são um deles. Um índice simples em uma coluna como email ou cpf reduz consultas de segundos para milissegundos em tabelas com mais de 100 mil linhas. Mas índice demais piora a performance de escrita. Eu já vi bancos onde a operação de insert demorava 300ms porque havia dezesseis índices em uma tabela de log que era escrita dezenas de vezes por segundo. A solução foi remover os índices das colunas que não eram usadas em where ou order by e manter apenas os essenciais. O insert caiu para 8ms. Outro exemplo que vale a pena mencionar é o uso de JSON em vez de tabelas normalizadas para dados semiestruturados. Colunas do tipo JSONB no PostgreSQL permitem armazenar atributos variáveis sem criar tabelas novas toda vez que surge um novo campo. Isso economiza migrações e alterações de schema. O contra é que você perde integridade referencial e queries mais complexas ficam mais difíceis de escrever e otimizar. Se os dados forem relativamente estáveis, a normalização tradicional ainda é mais segura. Se estão mudando frequentemente, JSONB resolve o problema.
Um detalhe importante sobre base de dados exemplos é que a maioria dos tutoriais mostra schema bonitos e limpos. Na vida real, você trabalha com dados sujos, colunas que deveriam ser FK mas não são, tipos errados herdados de versões anteriores. Um projeto meu tinha uma coluna data_cadastro como VARCHAR porque no início do sistema ninguém se preocupou com o tipo certo. Corrigir depois significava migrar todas as linhas, o que demorou horas em produção. A lição é simples: definir os tipos corretos desde o começo evita esse tipo de problema. Se tiver que mudar depois, faça em etapas com kolomnas temporárias e migração gradativa.
Exemplo de base de dados com relacionamento hierárquico
Departamentos e funcionários é um clássico que ilustra bem auto-relacionamento. Uma tabela funcionarios com uma coluna gestor_id que referencia a própria tabela permite representar a cadeia hierárquica. Consultar todos os subordinados diretos de um gestor é trivial com uma CTE recursiva no PostgreSQL ou MySQL 8+. O problema é que consultas recursivas profundas podem degradar a performance se a hierarquia tiver muitos níveis. Emorganizações com mais de cinco níveis de reporte, considere armazenar o caminho completo como uma string materializada, conhecida como materialized path. Isso simplifica Queries de subárvore mas exige quando há mudanças na estrutura. O tradeoff é padrão em qualquer base de dados: leitura rápida versus escrita rápida. Você escolhe um lado e vive com as consequências no outro. Não existe configuração que resolva ambos os lados perfeitamente.
