[BD] História 3: Lory e a Desnormalização no Sistema de E-commerce

Nessa história, vamos abordar temas de Desnormalização de um banco de dados

Lory continuou com problemas de performance no banco de dados, dessa vez ela foi ousada e resolveu fazer uma desnormalização de algumas tabelas para melhorar a performance. Inicialmente, a aplicação usava um modelo normalizado com tabelas para Ordem, Pedido, Cliente e NotaFiscal.

Consultas lentas em horários de pico.
Relatórios demorados, afetando as decisões estratégicas.
Sobrecarregamento do banco de dados, prejudicando integrações como o ERP.

A Desnormalização como uma possível Solução
Lory percebeu que muitas das consultas mais lentas envolviam joins complexos entre tabelas grandes. Por exemplo, um relatório básico de pedidos por cliente demorava vários minutos:

SELECT 
    c.ClienteID,
    c.Nome AS Cliente,
    COUNT(p.PedidoID) AS TotalPedidos,
    SUM(o.Quantidade * o.Preco) AS ValorTotal,
    MAX(nf.DataEmissao) AS UltimaNotaFiscal
FROM Cliente c
JOIN Pedido p ON c.ClienteID = p.ClienteID
JOIN Ordem o ON p.PedidoID = o.PedidoID
JOIN NotaFiscal nf ON p.PedidoID = nf.PedidoID
GROUP BY c.ClienteID, c.Nome;

Lory decidiu desnormalizar os dados, criando uma tabela que consolidava as informações frequentemente consultadas:

CREATE TABLE ResumoPedidos (
    ClienteID INT,
    Nome VARCHAR(100),
    TotalPedidos INT,
    ValorTotal DECIMAL(18, 2),
    UltimaNotaFiscal DATE
);

E preencheu os dados com uma query agendada periodicamente, um cron que rodava 1x por dia e executava a seguinte query em Postgre:

INSERT INTO ResumoPedidos
SELECT 
    c.ClienteID,
    c.Nome,
    COUNT(p.PedidoID),
    SUM(o.Quantidade * o.Preco),
    MAX(nf.DataEmissao)
FROM Cliente c
JOIN Pedido p ON c.ClienteID = p.ClienteID
JOIN Ordem o ON p.PedidoID = o.PedidoID
JOIN NotaFiscal nf ON p.PedidoID = nf.PedidoID
WHERE p.DtCriacao = CURRENT_DATE - INTERVAL '1 day'
GROUP BY c.ClienteID, c.Nome;

Obs. Os requisitos permitiam esse cenário, mas poderia ser em qualquer período, isso pode variar por necessidade de negócio.

Resultados da Desnormalização

• Consultas mais rápidas: Dados consolidados reduziram o tempo de execução de queries de minutos para segundos.
• Relatórios instantâneos: Relatórios complexos tornaram-se viáveis em tempo real.
• Integração facilitada: O ERP agora consumia dados da tabela desnormalizada, diminuindo sua dependência de joins pesados.

Limitações da Desnormalização
Apesar das melhorias, Lory enfrentou alguns desafios:

• Manutenção Complexa: Alterar os dados exigia sincronizar tabelas normalizadas e desnormalizadas.
• Armazenamento Adicional: Dados duplicados aumentaram o consumo de espaço.
• Dados Desatualizados: Se o processo de atualização falhasse, os relatórios poderiam apresentar informações inconsistentes.

Aprendizados
Quando a Desnormalização é Necessária

• A desnormalização é útil quando o sistema enfrenta gargalos de performance devido a joins complexos em tabelas grandes.
• É indicada em cenários onde a velocidade de leitura é mais importante que a consistência perfeita dos dados.
• Consultas complexas envolvendo várias tabelas (como JOIN e agregações) podem ser otimizadas armazenando dados consolidados em tabelas desnormalizadas.
• O armazenamento de dados pré-calculados reduz o tempo de execução de queries frequentes, tornando o sistema mais responsivo.