Banco de dados: o que eu nunca tinha entendido usando só como usuário

Na Oi, eu administrava sistemas que tinham banco de dados — mas nunca precisei entender o banco por dentro.

Meu trabalho era garantir que os serviços estavam rodando, que o backup estava funcionando, que o disco não estava cheio. Se banco ficava lento, o problema para mim era "banco lento" — eu escalava para quem entendia de banco. Não era minha área.

Quando a matéria de Banco de Dados chegou na faculdade, aprendi o que estava acontecendo dentro dos sistemas que eu tinha operado.

O que o modelo relacional resolve.

Antes de entender banco de dados, minha intuição para armazenar dados era: arquivo. Lista de registros em arquivo de texto, CSV, JSON. Funciona para casos simples.

O problema que banco relacional resolve é diferente: como armazenar dados de forma que você possa consultar de maneiras que você não previu quando armazenou? Como garantir que dados relacionados ficam consistentes mesmo quando múltiplas operações acontecem ao mesmo tempo? Como evitar que os mesmos dados precisem ser atualizados em múltiplos lugares?

Normalização é a resposta para o terceiro problema. A ideia de que cada fato deve existir em um único lugar — e outros lugares referenciam esse único lugar em vez de copiar o fato — parece óbvia depois de entender, mas não é óbvia antes.

SQL foi onde a maioria dos colegas teve dificuldade. Para mim, foi revelação.

Não porque era fácil — mas porque a linguagem era declarativa de uma forma que eu não tinha visto antes. Você descreve o que quer, não como obter. O banco decide o caminho.

SELECT u.nome, COUNT(p.id) as total_pedidos
FROM usuarios u
LEFT JOIN pedidos p ON u.id = p.usuario_id
WHERE u.criado_em > '2017-01-01'
GROUP BY u.id, u.nome
HAVING COUNT(p.id) > 5

Cada cláusula filtra, agrupa, transforma. A ordem de execução é diferente da ordem que você escreve. O banco otimiza o plano de execução com base em estatísticas que você não vê.

Isso é diferente de todo código procedural que eu tinha escrito.

O que me pegou: transações e o que "ACID" significa.

Atomicidade, Consistência, Isolamento, Durabilidade — as quatro propriedades que definem o que um banco de dados relacional garante.

Atomicidade: ou tudo da transação acontece, ou nada. Sem estados parciais. Consistência: transação só pode levar o banco de um estado válido para outro estado válido. Isolamento: transações concorrentes não interferem uma na outra. Durabilidade: depois que transação confirma, o dado persiste mesmo que o sistema caia.

Essas garantias existem para resolver problemas reais. Se você transfere dinheiro entre contas, você precisa que o débito em uma conta e o crédito em outra aconteçam como unidade atômica — ou nenhuma das duas, nunca só uma.

Eu tinha operado sistemas financeiros sem saber que isso era o que o banco estava garantindo.

O que mudou depois que aprendi banco de dados:

Quando um sistema era lento, eu conseguia fazer diagnóstico de primeira camada sozinho — verificar se a query estava fazendo full table scan, se índice estava sendo usado, se N+1 query estava acontecendo. Não precisava escalar imediatamente.

Quando revisei arquitetura de sistemas, comecei a pensar em modelo de dados: como os dados estão estruturados determina quais queries são eficientes. Decisão de schema é decisão de performance.

Quando discutia consistência eventual vs. consistência forte em sistemas distribuídos, tinha contexto do que exatamente estava sendo relaxado — e por que ACID completo tem custo em sistemas que escalam horizontalmente.

Banco de dados foi a matéria que mais preencheu gap entre o que eu operava e o que eu entendia.

Tinha operado sistemas que dependiam de banco por anos. Aprendi o que estava acontecendo. A lacuna era grande — e preenchê-la mudou como eu pensava sobre sistemas em geral.

Essa semana: qual camada do sistema que você usa todos os dias você nunca abriu para ver o que está acontecendo por dentro?