No nosso último post, aprendemos a usar o EXPLAIN para auditar a performance das nossas consultas. Mas conforme seu banco de dados cresce, suas queries inevitavelmente começam a acumular múltiplos JOINs, filtros complexos no WHERE e agrupamentos com GROUP BY.

Escrever essas queries gigantescas toda vez que a aplicação precisa de um dado — ou toda vez que você precisa gerar um relatório de infraestrutura — é cansativo, propenso a erros e quebra uma das regras de ouro do desenvolvimento: o princípio DRY (Don’t Repeat Yourself).

Como encapsular essa complexidade e reutilizar regras de negócio? No PostgreSQL, a resposta elegante para isso são as Views (Visualizações).

O que é uma View?

Pense em uma View como uma tabela virtual. Ela não armazena dados próprios fisicamente no disco. Em vez disso, uma View é simplesmente uma query SELECT gravada no catálogo do banco de dados com um nome específico.

💡 Como funciona: Quando você faz uma consulta a uma View, o PostgreSQL intercepta o pedido, roda a query que está guardada dentro dela por baixo dos panos e te entrega o resultado como se fosse uma tabela comum.

Exemplo Prático: O Cenário Sem View

Imagine que para gerar um relatório de custos de recursos alocados por cliente na sua infraestrutura Cloud, você precise rodar esta query robusta constantemente:

SELECT 
    c.nome AS cliente,
    cl.nome AS cluster,
    COUNT(s.id) AS total_servidores,
    SUM(s.vcpus) AS total_vcpus,
    SUM(s.memoria_gb) AS total_memoria
FROM clientes c
INNER JOIN clusters cl ON cl.id_cliente = c.id
INNER JOIN servidores s ON s.id_cluster = cl.id
WHERE s.status = 'ativo'
GROUP BY c.nome, cl.nome;

Ficar copiando e colando esse bloco de código no seu backend ou nos scripts de automação é um pesadelo de manutenção. Se a regra de negócio mudar (por exemplo, se você precisar passar a considerar servidores em ‘manutenção’), você terá que caçar e alterar essa query em todos os lugares do seu código.

A Solução Elegante: Criando a View

Vamos encapsular toda essa complexidade criando uma View chamada vw_resumo_recursos_cliente:

CREATE VIEW vw_resumo_recursos_cliente AS
SELECT 
    c.nome AS cliente,
    cl.nome AS cluster,
    COUNT(s.id) AS total_servidores,
    SUM(s.vcpus) AS total_vcpus,
    SUM(s.memoria_gb) AS total_memoria
FROM clientes c
INNER JOIN clusters cl ON cl.id_cliente = c.id
INNER JOIN servidores s ON s.id_cluster = cl.id
WHERE s.status = 'ativo'
GROUP BY c.nome, cl.nome;

Pronto! Agora a complexidade está escondida dentro do banco. Para obter exatamente o mesmo relatório, a sua aplicação ou o seu dashboard de BI só precisa rodar isso aqui:

SELECT * FROM vw_resumo_recursos_cliente;

Você pode até aplicar filtros adicionais na View, como se ela fosse uma tabela real:

SELECT * FROM vw_resumo_recursos_cliente 
WHERE total_vcpus > 64;

Vantagens de Usar Views em Projetos de Dados e DevOps

1. Segurança e Mascaramento de Dados: Você pode criar uma View que expõe apenas colunas não sensíveis de uma tabela de usuários para uma ferramenta de analytics, deixando campos como senha_hash ou documentos totalmente inacessíveis para aquele usuário do banco.
2. Centralização de Regras de Negócio: Se a definição de “servidor ativo” mudar amanhã, você só altera a query dentro da View (CREATE OR REPLACE VIEW...). Todo o ecossistema que consome essa visualização se atualiza automaticamente.
3. Abstração para o Desenvolvedor: O time de desenvolvimento do backend não precisa entender como a modelagem de dados foi normalizada em 5 tabelas diferentes. Eles só precisam saber o nome da View que entrega o dado mastigado.

E a Performance? (Atenção com Views Comuns)

Como as Views normais não guardam dados em disco, elas não aceleram a query magicamente. Toda vez que você chama uma View, o Postgres executa todos os JOINs internos novamente. Se a query por trás da View for lenta, chamar a View continuará sendo lento.

Para cenários onde o volume de dados é gigantesco e precisamos de performance extrema para relatórios, o PostgreSQL oferece um recurso avançado chamado Materialized Views (Visualizações Materializadas), que salvam o resultado da query fisicamente em disco e podem receber índices próprios. Mas esse é um assunto avançado que veremos mais para a frente!

Conclusão

As Views são ferramentas fantásticas para limpar o código das suas aplicações, centralizar a inteligência das métricas da sua infraestrutura e garantir que todo o time fale a mesma língua quando o assunto é extração de dados.

Com o entendimento de tabelas, inserts, filtros, agrupamentos, índices, joins e agora views, você já tem uma base sólida para operar qualquer banco relacional no mercado.

No próximo post da nossa seção de SQL, vamos entrar no universo das modificações de estruturas em produção. Vamos aprender a usar o comando ALTER TABLE de forma segura, entendendo o impacto de alterar colunas e restrições em ambientes vivos (live environment) sem causar downtime. Até lá!

Você já utiliza Views para simplificar as queries dos seus dashboards ou costuma escrever os JOINs direto na aplicação? Deixe sua experiência aqui nos comentários!