Olá pessoal, tudo tranquilo?
Neste post veremos uma explicação inicial sobre o que é uma View, uma Materialized View, para que servem e que tipo de ganho podemos obter ao utilizá-las.

Provavelmente teremos mais alguns posts, aonde iremos aprofundando sobre este assunto e mostrando como podemos usar a gem Scenic (ops, spoiler aqui) para nos auxiliar quando trabalhando com Rails.

O que é uma View no Banco de Dados?

Uma view em um banco de dados é uma consulta pré-definida que age como uma “tabela virtual”. Ela não armazena dados por si só, mas sim o resultado de uma consulta SQL que é executada toda vez que a view é acessada. Em outras palavras, a view é um conjunto de dados dinâmico, sempre atualizado conforme as tabelas subjacentes.

Views são especialmente úteis para simplificar consultas complexas, pois permitem encapsular lógica SQL detalhada em uma “tabela” que pode ser usada como qualquer outra, mas sem a necessidade de armazenar os dados permanentemente.

Exemplo Prático: Usando Views para Simplificar Consultas Complexas

Imagine que você possui um sistema de e-commerce com tabelas que guardam dados sobre pedidos, clientes e produtos, e você deseja criar uma consulta para exibir informações sobre vendas mensais, incluindo o cliente, o produto, a quantidade e o valor total.

Se essa consulta for complexa e precisa ser acessada frequentemente, podemos encapsulá-la em uma view para simplificar o acesso.

CREATE VIEW monthly_sales AS
SELECT 
    c.name AS customer_name,
    p.name AS product_name,
    SUM(oi.quantity) AS total_quantity,
    SUM(oi.quantity * oi.unit_price) AS total_sales,
    EXTRACT(MONTH FROM o.order_date) AS sales_month,
    EXTRACT(YEAR FROM o.order_date) AS sales_year
FROM 
    orders o
JOIN 
    order_items oi ON o.id = oi.order_id
JOIN 
    products p ON oi.product_id = p.id
JOIN 
    customers c ON o.customer_id = c.id
GROUP BY 
    c.name, p.name, sales_month, sales_year;

Essa view, monthly_sales, agora age como uma “tabela virtual” e pode ser usada para simplificar futuras consultas sobre vendas mensais:

SELECT * FROM monthly_sales WHERE sales_month = 1 AND sales_year = 2024;

O que é uma Materialized View ?

Diferente de uma view convencional, que é uma tabela virtual gerada dinamicamente, uma materialized view é uma “tabela persistente” que armazena os dados resultantes de uma consulta complexa. Em outras palavras, o resultado da consulta é calculado uma vez e salvo no banco, permitindo consultas extremamente rápidas, já que não é necessário recalcular os dados a cada acesso.

No entanto, as materialized views não se atualizam automaticamente: se os dados subjacentes mudarem, a materialized view precisa ser atualizada explicitamente. Isso é feito por meio de um comando específico (como REFRESH MATERIALIZED VIEW no PostgreSQL), o que pode ser configurado em intervalos regulares, dependendo das necessidades do sistema.

Exemplo Prático: Materialized View para Otimizar Consultas de Relatórios

Continuando com o exemplo do e-commerce, imagine que você precise gerar relatórios de vendas anuais, o que envolve processamento de uma quantidade grande de dados históricos e cálculos complexos.

Em vez de calcular esses dados a cada nova consulta, podemos criar uma materialized view para armazenar os resultados, otimizando as futuras consultas.

CREATE MATERIALIZED VIEW annual_sales AS
SELECT 
    p.name AS product_name,
    SUM(oi.quantity) AS total_quantity,
    SUM(oi.quantity * oi.unit_price) AS total_sales,
    EXTRACT(YEAR FROM o.order_date) AS sales_year
FROM 
    orders o
JOIN 
    order_items oi ON o.id = oi.order_id
JOIN 
    products p ON oi.product_id = p.id
GROUP BY 
    p.name, sales_year;

Agora, o acesso aos dados agregados para relatórios anuais de vendas será muito mais rápido, pois o banco não precisará recalcular todos os dados a cada consulta:

SELECT * FROM annual_sales WHERE sales_year = 2023;

Para garantir que a materialized view esteja atualizada, você precisa periodicamente executar:

REFRESH MATERIALIZED VIEW annual_sales;

Prós e Contras das Views e Materialized Views

Quando devemos usar cada uma?

• Views:
  • Quando a consulta é leve e não executada com muita frequência.
  • Para encapsular consultas complexas em uma camada de abstração, facilitando o acesso a dados.
  • Em cenários onde a precisão e atualidade dos dados são mais importantes do que o desempenho, como em relatórios que sempre precisam refletir o estado atual do banco.
• Materialized Views:
  • Para otimizar consultas que envolvem muitos cálculos e agregações, como relatórios anuais ou estatísticas sobre grandes volumes de dados.
  • Quando os dados não mudam com frequência e as consultas são muito intensivas, como um painel de métricas de vendas históricas.
  • Em situações onde é mais importante que a consulta seja rápida do que os dados estarem sempre 100% atualizados, como em relatórios financeiros fechados mensalmente.

Concluindo

Quando você perceber que tem uma consulta que está se tornando complexa demais, trazendo dados de diversas tabelas, uma view provavelmente pode ser a melhor maneira de simplificar sua vida. Entretanto, se você faz uma consulta complexa, mas que além de tudo faz cálculos, tem lógicas dentro e com uma frequência razoável, que está lenta, a materialized view será provavelmente a indicada para solucionar o seu problema (sério, você deveria experimentar).
Estas 2 opções são recursos poderosos de bancos de dados relacionais, tendo um potencial enorme, melhorando demais o tempo de execução de uma consulta e/ou a simplificando.

Quer saber mais sobre views e banco de dados:

• Curso na DataCamp (gratuito na data atual)
• Trilha banco de dados – Fundação Bradesco
• GeeksForGeeks – SQL Views
• Views in Relational Databases- Rishabh Agarwal
• Materialized Views in Ruby on Rails with scenic – Paweł Michna