Entendendo a camada física do projeto de banco de dados
Quando você chega no volume 4 do projeto de banco de dados, já passou por modeling conceitual, lógico e início da normalização. O que sobra é a parte que poucos gostam de ler: implementação física, indexação, particionamento, acoplamento com o SGBD e tudo mais que transforma um diagrama bonito em coisa que roda no servidor sem travar às três da manhã. Eu já vi gente travar aqui porque acha que o volume anterior já resolveu o problema. Não resolve. A diferença entre o design lógico e o físico é enorme. No lógico você declara chaves estrangeiras e constraints bonitinhas. No físico você descobre que aquele índice composto que parecia perfeito está causando lock contention no.projeto de banco de dados: volume 4 — o que realmente acontece
O volume 4 foca na tradução do modelo para a realidade do SGBD escolhido. Isso envolve definições de tipos de dado que refletem os limites da máquina, configurações de engine de armazenamento, estratégias de particionamento quando o volume de linhas ultrapassa o que cabe comfortably em memória, e o mapeamento de constraints para a sintaxe específica do PostgreSQL, MySQL, SQL Server ou Oracle. Um erro comum é tratar a criação dos objetos como algo trivial. Eu já perdi meio dia depurando uma query que parecia correta no modelo e rodava em 200ms, mas na implementação real pegava 14 segundos porque o otimizador escolheu o plano errado. O problema? Uma coluna varchar(255) que deveria ser enum, e um índice covering que não cobria a cláusula WHERE por causa de uma conversão implícita de tipo. A solução foi criar uma function de wrapping que forçava o cast explícito e adicionar um hint de query que direcionava para o índice correto. Isso é detalhe que só aparece depois que o sistema está em produção.
O particionamento merece atenção especial. A tentação é particionar tudo por data logo de cara, mas particionar uma tabela com menos de 5 milhões de linhas geralmente é overhead sem benefício. A regra prática que eu uso é: se a tabela cresce mais de 10% ao ano e as queries mais pesadas têm predicado de data, particiona. Senão, deixe para quando o problema existir. Particionamento prematuro cria manutenção desnecessária e complexity que ninguém pede. Outro ponto que ninguém comenta direito: a escolha entre clustered e non-clustered indexes. No SQL Server isso é crítico porque só existe um clustered index por tabela. No PostgreSQL não existe clustered index no mesmo sentido. No MySQL com InnoDB, a tabela o clustered index. Se você não mapear essas diferenças na hora do projeto, acaba com queries que seriam simples virando scans completos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Indexação também é onde a maioria erra. A estratégia mais segura é começar com índices únicos nas foreign keys e nas colunas mais frequentemente usadas em WHERE e JOIN. Índices compostos devem seguir a ordem de seletividade: a coluna mais seletiva primeiro. Eu costumo calcular a cardinalidade antes de criar qualquer índice. Se uma coluna tem menos de 10 valores distintos em 10 milhões de linhas, um índice nela raramente ajuda e às vezes piora a performance porque o otimizador passa mais tempo decidindo se usa ou não. Para monitoramento, configure logging de slow queries desde o primeiro dia. No PostgreSQL use log_min_duration_statement = 200. No MySQL ative o slow query log e monitore com pt-query-digest. Sem dados reais de uso, qualquer decisão de indexação é adivinhação.
Existe um trade-off que vale a pena mencionar: cada índice adicionado acelera reads mas desacelera writes. Em tabelas com alta taxa de INSERT e UPDATE, índices extras podem reduzir o throughput em até 30%. Eu já vi um caso onde uma tabela de logs com 5 índices adicionais caía de 15 mil INSERTs por segundo para cerca de 10 mil. Removi dois índices que não eram usados em nenhuma query frequente e voltei ao patamar esperado. A normalização não para no volume 3. Desnormalizações controladas são aceitáveis e comuns em projetos de escala. A chave é documentar cada desnormalização com um comentário no DDL explicando o porquê. Sinonimização de colunas, tabelas materializadas, colunas derivadas calculadas: tudo isso é válido desde que haja registro claro de intenção.
Backup e recovery também entram no volume 4, mesmo que pareça cedo. Definir RPO e RTO antes de ir para produção evita dor de cabeça. Um projeto bem executado nessa fase reduz o tempo de restore de horas para minutos em cenários de falha.
