História 2: Lory e a Criação de Views no Sistema de E-commerce

Nessa história, vamos abordar temas de Views de um banco de dados

O Crescimento do Sistema
Depois de solucionar os problemas de performance com indexação, Lory viu o e-commerce prosperar. Porém, como todo sistema em crescimento, novos desafios surgiram. Os lojistas começaram a solicitar relatórios mais detalhados, como pedidos consolidados por cliente, produtos mais vendidos e informações fiscais. Além disso, a integração com o ERP da empresa tornou-se essencial para automatizar processos.

Essas novas demandas sobrecarregaram o sistema. Consultas complexas que uniam tabelas como Ordem, Pedido, Cliente e NotaFiscal começaram a impactar a performance. Relatórios que deveriam ser gerados em minutos passaram a levar horas, afetando o atendimento aos lojistas.

O Problema de Performance
Lory percebeu que o gargalo estava nas consultas que uniam grandes tabelas. Uma das queries problemáticas era:

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;

Essa consulta fazia leituras demoradas nas tabelas e consumia muitos recursos do banco de dados, especialmente em horários de pico.

A Solução com Views
Lory encontrou a solução nas views do banco de dados. Ela percebeu que poderia criar uma estrutura pré-processada para consolidar os dados frequentemente utilizados, reduzindo o tempo de execução das consultas.

A Criação da View
Lory criou uma view para consolidar as informações mais usadas pelos relatórios e pelo ERP:

CREATE VIEW vw_ResumoPedidos AS
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;

Agora, em vez de executar a consulta diretamente nas tabelas, o sistema poderia acessar a view:

SELECT * FROM vw_ResumoPedidos WHERE ClienteID = 12345;

O Resultado
Com a criação da view:

• Consultas complexas que antes levavam minutos agora eram respondidas em segundos.
• Relatórios passaram a ser gerados mais rapidamente.
• A integração com o ERP foi simplificada, pois o sistema podia acessar dados consolidados diretamente na view.

As Limitações e os Novos Desafios
Apesar do sucesso inicial, Lory percebeu algumas limitações no uso de views:

Problemas Identificados

• Views Não Indexadas: Consultas em views sem índices eram lentas em tabelas muito grandes.
• Manutenção Difícil: Alterações nas tabelas base exigiam que Lory ajustasse a lógica da view.
• Uso de Recursos: Views complexas consumiam muitos recursos do banco de dados em horários de alta demanda.

O Impacto na Integração com o ERP
Ao integrar o sistema com o ERP, o volume de dados acessado aumentou ainda mais. O ERP dependia da view para consolidar informações, e em horários de pico, as consultas começaram a afetar novamente o desempenho geral do sistema.

A Solução para Escalabilidade
Lory sabia que precisava otimizar ainda mais o sistema. Ela implementou as seguintes melhorias:

1. Views Materializadas
Para evitar que a view recalculasse os dados a cada consulta, Lory criou uma view materializada:

CREATE MATERIALIZED VIEW mv_ResumoPedidos AS
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;

A view materializada armazenava os dados pré-calculados, reduzindo o custo das consultas subsequentes.

2. Atualizações Periódicas
Para manter os dados da view atualizados, ela configurou um processo periódico:

REFRESH MATERIALIZED VIEW mv_ResumoPedidos;

Lições Aprendidas

• Views Simplificam Consultas: Consolidar dados com views reduz o tempo de execução de consultas complexas.
• Manutenção Regular é Essencial: Views materializadas precisam de atualizações periódicas para garantir dados consistentes.
• Equilíbrio entre Simplicidade e Performance: Soluções como views materializadas e particionamento exigem planejamento para evitar complexidade excessiva.

Com essas melhorias, o sistema de Lory tornou-se mais escalável e capaz de suportar o crescimento do e-commerce e a integração com o ERP. Os lojistas estavam felizes, e Lory continuava a aprender e aplicar novas estratégias para enfrentar desafios futuros.

Referencias
https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html
https://www.postgresql.org/docs/17/sql-creatematerializedview.html
https://www.postgresql.org/docs/17/sql-createview.html