Para resolver isso, utilizamos as Views (ou Visões).

O que é uma View?

Uma view (ou visão) é uma tabela virtual criada a partir de uma consulta SQL. Ela não armazena dados por si mesma, em vez disso, é uma “janela” que sempre exibe o resultado de uma query pré-definida, como se fosse uma tabela real.

Pense em uma view como um atalho salvo para uma consulta complexa. Quando você consulta uma view, o banco de dados executa a query por trás dela e retorna o resultado, como se você estivesse consultando uma tabela comum.

Veja como uma view se posiciona na arquitetura de um banco de dados:

Por que criar uma view?

1. Simplicidade e reutilização

Queries longas e com muitos JOINs podem ser encapsuladas em uma view e reutilizadas em vários lugares, sem repetição de código.

2. Segurança e controle de acesso

Views permitem expor apenas os dados que um usuário ou sistema pode ver, sem dar acesso direto às tabelas.

3. Abstração e manutenção

Se a estrutura do banco mudar, você atualiza apenas a view — as aplicações que a consomem não precisam saber o que mudou por baixo.

Como criar uma view: Exemplos práticos

Exemplo 1 — Criando uma view simples

-- Criando uma view simples
CREATE VIEW resumo_clientes AS
SELECT
    c.id,
    c.nome,
    COUNT(p.id) AS total_pedidos,
    SUM(p.valor) AS valor_total
FROM clientes c
LEFT JOIN pedidos p ON p.cliente_id = c.id
GROUP BY c.id, c.nome;

-- Consultando a view como se fosse uma tabela
SELECT * FROM resumo_clientes WHERE valor_total > 1000;

-- Criando uma view simples
CREATE VIEW resumo_clientes AS
SELECT
    c.id,
    c.nome,
    COUNT(p.id) AS total_pedidos,
    SUM(p.valor) AS valor_total
FROM clientes c
LEFT JOIN pedidos p ON p.cliente_id = c.id
GROUP BY c.id, c.nome;

-- Consultando a view como se fosse uma tabela
SELECT * FROM resumo_clientes WHERE valor_total > 1000;

Exemplo 2 — relatório de vendas por mês:

CREATE VIEW vendas_mensais AS
SELECT
    DATE_TRUNC('month', data_pedido) AS mes,
    COUNT(*) AS quantidade_pedidos,
    SUM(total) AS receita_total,
    AVG(total) AS ticket_medio
FROM pedidos
WHERE status = 'concluido'
GROUP BY DATE_TRUNC('month', data_pedido)
ORDER BY mes DESC;

-- Uso:
SELECT * FROM vendas_mensais WHERE mes >= '2024-01-01';

CREATE VIEW vendas_mensais AS
SELECT
    DATE_TRUNC('month', data_pedido) AS mes,
    COUNT(*) AS quantidade_pedidos,
    SUM(total) AS receita_total,
    AVG(total) AS ticket_medio
FROM pedidos
WHERE status = 'concluido'
GROUP BY DATE_TRUNC('month', data_pedido)
ORDER BY mes DESC;

-- Uso:
SELECT * FROM vendas_mensais WHERE mes >= '2024-01-01';

Neste vídeo, falo sobre como criar uma View no phpMyAdmin para otimizar consultas no banco de dados de forma simples e eficiente:

Materialized Views: Quando performance importa

Views comuns executam a query toda vez que são consultadas. Para queries muito pesadas, existe o conceito de materialized view, que armazena fisicamente o resultado e pode ser atualizada periodicamente.

-- PostgreSQL: criando uma materialized view
CREATE MATERIALIZED VIEW estatisticas_diarias AS
SELECT
    DATE(criado_em) AS dia,
    COUNT(*) AS novos_usuarios,
    SUM(receita) AS receita_do_dia
FROM eventos
GROUP BY DATE(criado_em);

-- Atualizando os dados armazenados
REFRESH MATERIALIZED VIEW estatisticas_diarias;

-- PostgreSQL: criando uma materialized view
CREATE MATERIALIZED VIEW estatisticas_diarias AS
SELECT
    DATE(criado_em) AS dia,
    COUNT(*) AS novos_usuarios,
    SUM(receita) AS receita_do_dia
FROM eventos
GROUP BY DATE(criado_em);

-- Atualizando os dados armazenados
REFRESH MATERIALIZED VIEW estatisticas_diarias;

É importante conhecer essa diferença, especialmente se você trabalha com grandes volumes de dados:

• View Comum: É apenas um “atalho”. Toda vez que você a chama, o banco executa o SELECT original. Se a tabela base mudar, a View reflete a mudança na hora.
• Materialized View (View Materializada): Muito comum em Data Warehouses (como Snowflake, Oracle ou Redshift). Ela salva o resultado da consulta fisicamente no disco.
  • Vantagem: É infinitamente mais rápida para leitura em tabelas gigantes.
  • Desvantagem: Os dados podem ficar desatualizados (é necessário dar um “refresh” manual ou agendado para atualizar os dados).

Qual é a diferença entre uma View, um Tabela e uma consulta AD-HOC?

• Tabelas: São estruturas físicas que armazenam dados diretamente no banco. Elas são a base de qualquer banco de dados relacional.
• Views: São consultas armazenadas que não armazenam dados por si mesmas, servindo como uma camada de abstração para facilitar o acesso a informações complexas.
• Consultas ADHOC: Uma consulta SQL que é executada de forma esporádica ou para responder a uma necessidade específica, sem estar previamente salva como uma view ou estrutura fixa.

💡 Quando usar uma View?
Se você deseja simplificar consultas, ocultar dados sensíveis ou organizar melhor as informações sem criar cópias dos dados.

💡 Quando usar uma Tabela?
Sempre que precisar armazenar dados de forma persistente e garantir que sejam acessados com alta performance.

💡 Quando usar uma Consulta ADHOC?
Sempre que precisar responder alguma pergunta temporária que não precisa ser consumida posteriormente

O post Views e Materialized Views em Bancos de Dados apareceu primeiro em Data Universe.

A Analogia Clássica: O Índice de um Livro

Imagine que você está lendo um livro de História de 1.000 páginas e quer encontrar todas as menções a “Júlio César”.

• Sem um índice (Full Table Scan): Você teria que ler o livro inteiro, da página 1 à 1.000, procurando o nome. No banco de dados, isso se chama Full Table Scan (Varredura Completa da Tabela), e é o pior cenário para a performance.
• Com um índice (Index Scan): Você vai até as últimas páginas do livro, no Índice Remissivo, procura a letra “J”, acha “Júlio César” e vê que ele é citado nas páginas 45, 112 e 890. Você vai direto a essas páginas.

Um índice de banco de dados faz exatamente isso: ele cria uma estrutura de dados separada (geralmente uma árvore chamada B-Tree) que mantém os valores de uma coluna específica ordenados, junto com um “ponteiro” (o número da página) que diz exatamente onde a linha inteira está gravada no disco.

O Preço a se Pagar (Trade-offs)

Se os índices deixam tudo mais rápido, por que não colocamos índices em todas as colunas de todas as tabelas?

Porque índices não são mágicos; eles têm um custo.

1. Overhead de Escrita (Lentidão no CRUD): Toda vez que você faz um INSERT, UPDATE ou DELETE na tabela, o banco de dados precisa atualizar a tabela principal E reorganizar a estrutura do índice. Muitos índices deixam as gravações muito lentas.
2. Consumo de Disco: O índice é uma cópia ordenada dos dados daquela coluna. Ele ocupa espaço físico no servidor. Um banco de dados super indexado pode ter seus índices ocupando mais gigabytes do que os próprios dados reais.

Quando Usar (e Quando NÃO Usar) Índices

A arte da otimização de banco de dados está em saber equilibrar a balança entre a velocidade de leitura e o custo de escrita.

Onde você DEVE criar índices:

• Chaves Primárias (PK) e Estrangeiras (FK): (Bancos relacionais geralmente criam o índice da PK automaticamente). Essencial para que os JOINs entre tabelas sejam rápidos.
• Colunas muito usadas no WHERE: Se você pesquisa clientes pelo CPF o tempo todo, a coluna cpf precisa de um índice.
• Colunas usadas em ORDER BY ou GROUP BY: Como o índice já guarda os dados de forma ordenada, o banco não gasta processamento extra para ordenar o resultado.

Onde você NÃO DEVE criar índices:

• Tabelas muito pequenas: Se a tabela tem 500 linhas, o banco lê tudo em milissegundos. O índice só gastaria espaço.
• Colunas de Baixa Cardinalidade: Colunas com poucos valores distintos, como sexo (M/F) ou status (Ativo/Inativo). O índice não ajuda a filtrar muita coisa e o banco pode acabar optando pelo Full Table Scan de qualquer jeito.
• Tabelas com altíssimo volume de inserção (Logs): Se uma tabela recebe milhares de INSERTS por segundo e é pouco lida, um índice vai criar um gargalo de gravação.

Exemplos Práticos em Código SQL

Vamos ver como aplicar isso na prática usando SQL. Imagine uma tabela Clientes com milhões de registros.

1. Criando um Índice Simples

Se o time de vendas sempre busca clientes pelo e-mail, criar um índice nessa coluna vai transformar uma busca que demorava 10 segundos em algo que leva 5 milissegundos.

-- Criando um índice simples na coluna email
CREATE INDEX idx_clientes_email 
ON Clientes (email);

-- Criando um índice simples na coluna email
CREATE INDEX idx_clientes_email 
ON Clientes (email);

2. Criando um Índice Único (Unique Index)

Além de acelerar a busca, ele garante a integridade dos dados, impedindo que dois clientes sejam cadastrados com o mesmo CPF.

-- Criando um índice único na coluna cpf
CREATE UNIQUE INDEX idx_clientes_cpf 
ON Clientes (cpf);

-- Criando um índice único na coluna cpf
CREATE UNIQUE INDEX idx_clientes_cpf 
ON Clientes (cpf);

3. Criando um Índice Composto (Composite Index)

Se você tem uma consulta que SEMPRE filtra por duas colunas ao mesmo tempo (ex: buscar vendas de uma loja específica em uma data específica), você pode criar um índice que combina as duas colunas.

-- Índice composto: a ordem das colunas importa!
CREATE INDEX idx_vendas_loja_data 
ON Vendas (id_loja, data_venda);

-- Índice composto: a ordem das colunas importa!
CREATE INDEX idx_vendas_loja_data 
ON Vendas (id_loja, data_venda);

(Nota: Esse índice é excelente para consultas como WHERE id_loja = 5 AND data_venda = '2026-03-11', mas não ajudaria em nada se você buscasse APENAS pela data_venda).

4. Removendo um Índice

Se você percebeu que um índice não está sendo usado e está apenas atrasando suas inserções, você deve excluí-lo.

-- Removendo o índice do banco de dados
DROP INDEX idx_clientes_email;

-- Removendo o índice do banco de dados
DROP INDEX idx_clientes_email;

DataWarehouses Modernos não utilizam índices tradicionais.

Bancos de dados tradicionais (OLTP) usam índices B-Tree para encontrar uma agulha no palheiro (uma linha específica). Já o BigQuery e o Snowflake são bancos Orientados a Colunas (Columnar Databases) projetados para análise massiva de dados (OLAP).

Em vez de índices, eles usam três conceitos automáticos:

1. Micro-particionamento (Automático): No Snowflake, por exemplo, os dados são divididos em arquivos minúsculos chamados micro-partitions. O sistema sabe o valor mínimo e máximo de cada coluna em cada arquivo e descarta o que não precisa ler.
2. Metadata Cache: O banco mantém metadados sobre onde cada dado está. Ele não precisa de você para “criar” o caminho; ele faz isso sozinho.
3. Clustering: É o “primo” do índice nessas ferramentas. Você define uma Clustering Key para dizer ao banco: “Organize esses dados fisicamente por data e região”. Isso agrupa os dados de forma eficiente.

Como saber se uma tabela tem “índices” (ou otimizações) em Data Warehouses modernos

Se você está em um banco tradicional, você procura por Indexes. Se você está em BigQuery/Snowflake, você procura por Clustering e Partitioning.

1. No Snowflake

O Snowflake não tem índices. Se você quer saber como uma tabela foi otimizada, você deve checar as Clustering Keys.

• Via interface: Vá na aba “Data”, selecione a tabela e procure por “Clustering Information”.
• Via código SQL:

-- Mostra detalhes da tabela, incluindo as chaves de agrupamento (clustering)
SHOW TABLES LIKE 'nome_da_minha_tabela';
-- Verifique a coluna 'cluster_by' no resultado.

-- Mostra detalhes da tabela, incluindo as chaves de agrupamento (clustering)
SHOW TABLES LIKE 'nome_da_minha_tabela';
-- Verifique a coluna 'cluster_by' no resultado.

2. No BigQuery

O BigQuery usa Partitioning (geralmente por data) e Clustering.

• Via interface: Clique na tabela e vá na aba “Details”. Procure pelas seções “Table info” (onde diz se é particionada) e “Schema” (onde as colunas de cluster aparecem com um ícone específico).
• Via código SQL:

-- Consulta os metadados das tabelas no dataset
SELECT table_name, ddl 
FROM `meu_projeto.meu_dataset.INFORMATION_SCHEMA.TABLES`
WHERE table_name = 'nome_da_tabela';
-- No DDL (o código de criação), você verá as cláusulas PARTITION BY e CLUSTER BY.

-- Consulta os metadados das tabelas no dataset
SELECT table_name, ddl 
FROM `meu_projeto.meu_dataset.INFORMATION_SCHEMA.TABLES`
WHERE table_name = 'nome_da_tabela';
-- No DDL (o código de criação), você verá as cláusulas PARTITION BY e CLUSTER BY.

3. Em Bancos Tradicionais (Postgres, SQL Server, MySQL)

Se você cair em um projeto que usa bancos relacionais comuns, você usa as tabelas de sistema:

-- Exemplo para PostgreSQL: Lista todos os índices de uma tabela
SELECT * FROM pg_indexes WHERE tablename = 'nome_da_tabela';

-- Exemplo genérico (muitas ferramentas de BI mostram isso na lateral):
-- Procure por uma pasta chamada "Indexes" na árvore de objetos do banco.

-- Exemplo para PostgreSQL: Lista todos os índices de uma tabela
SELECT * FROM pg_indexes WHERE tablename = 'nome_da_tabela';

-- Exemplo genérico (muitas ferramentas de BI mostram isso na lateral):
-- Procure por uma pasta chamada "Indexes" na árvore de objetos do banco.

Dica para Arquitetos e Engenheiros

Índices são a ponte entre um sistema que “funciona” e um sistema que escala. Em um curso de Engenharia de Dados, esse tema é o divisor de águas que ensina os alunos a pararem de culpar o “servidor fraco” e começarem a olhar para a estrutura física das suas consultas.

O post Índices de Banco de Dados (Database Indexes) apareceu primeiro em Data Universe.

É aqui que entram duas das arquiteturas mais importantes da Engenharia de Dados e de Software: Partitioning (Particionamento) e Sharding (Fragmentação). Embora frequentemente confundidos, eles resolvem problemas de escala de maneiras fundamentalmente diferentes.

O que é Partitioning (Particionamento)?

O particionamento é a técnica de dividir uma tabela lógica muito grande em pedaços físicos menores e mais gerenciáveis, dentro do mesmo banco de dados ou servidor. O sistema de banco de dados gerencia essas partições de forma transparente; para a aplicação, parece que ela ainda está consultando uma única tabela gigante.

Existem dois tipos principais de particionamento:

O que é Sharding (Fragmentação)?

O Sharding é, na verdade, uma forma extrema de particionamento horizontal. A diferença crucial é a infraestrutura: no Sharding, os dados são divididos e distribuídos em múltiplos servidores físicos ou instâncias de banco de dados independentes (chamados de Shards).

Nesta arquitetura, conhecida como Shared-Nothing (Nada Compartilhado), cada Shard atua como um banco de dados autônomo contendo apenas uma fatia dos dados totais.

• Como funciona: Uma “Chave de Shard” (Shard Key) determina para qual servidor o dado vai. Se você fizer o sharding por “Região”, o Shard A pode guardar os clientes do Brasil, o Shard B os dos EUA, e o Shard C os da Europa.
• Por que usar: Quando um único servidor (mesmo o mais caro e potente do mercado) não tem mais CPU, RAM ou disco suficiente para lidar com o volume de dados ou de requisições simultâneas. O Sharding permite escalabilidade horizontal infinita: basta adicionar mais servidores baratos ao cluster.

Principais Diferenças

A tabela abaixo destaca o contraste direto entre as duas abordagens:

Particionamento na Prática: O E-commerce e o Relatório Lento

Imagine que você trabalha na engenharia de dados de um grande e-commerce. Vocês têm uma tabela chamada Pedidos no PostgreSQL que armazena todas as vendas desde a fundação da empresa, há 10 anos. Essa tabela tem 5 bilhões de linhas.

O Problema:

Toda vez que o time de marketing tenta puxar um relatório das “vendas de ontem”, a query demora minutos para rodar. Além disso, o índice dessa tabela ficou tão gigante que não cabe mais na memória RAM do servidor (que custa caro).

A Solução (Particionamento Horizontal por Data):

Você decide particionar a tabela Pedidos por mês e ano.

• Como fica nos bastidores: O banco de dados cria tabelas físicas menores “escondidas” (ex: pedidos_2025_12, pedidos_2026_01, pedidos_2026_02).
• A Mágica (Partition Pruning): Quando o marketing roda um SELECT * FROM Pedidos WHERE data = '04/03/2026', o banco de dados é inteligente o suficiente para saber que não precisa ler a tabela inteira. Ele vai direto na partição pedidos_2026_03 e ignora todo o resto. O relatório que demorava minutos passa a rodar em milissegundos.
• Manutenção: Se a política da empresa diz que dados com mais de 5 anos devem ser apagados, você não roda um comando DELETE (que travaria o banco e consumiria muito processamento). Você simplesmente roda um DROP PARTITION pedidos_2021_01. A exclusão de milhões de linhas acontece instantaneamente, liberando espaço no disco.

Agora imagine que você é o arquiteto de um sistema de CRM (SaaS) global, parecido com o Salesforce. Vocês têm milhares de empresas como clientes.

O Problema:

O sistema faz 100.000 gravações (inserções e atualizações) por segundo. O servidor de banco de dados atual chegou a 100% de uso de CPU, a memória RAM está no limite e o disco não consegue gravar dados mais rápido do que isso. Fazer um particionamento não vai ajudar, porque a máquina física não aguenta mais o tráfego.

A Solução (Sharding Baseado em ID do Cliente):

Você decide transformar seu banco de dados único em um cluster de múltiplos servidores independentes (Shards). Você escolhe o id_empresa como a sua Chave de Shard (Shard Key).

• Como fica nos bastidores:
  • Servidor 1 (Shard A): Armazena todos os dados das Empresas de ID 1 a 10.000.
  • Servidor 2 (Shard B): Armazena todos os dados das Empresas de ID 10.001 a 20.000.
  • Servidor 3 (Shard C): Armazena todos os dados das Empresas de ID 20.001 a 30.000.
• A Mágica (Roteamento): Quando um funcionário da Empresa 15.000 faz login e tenta salvar um novo cliente no CRM, a sua aplicação (ou um roteador de banco de dados intermediário) avalia a requisição. Ele vê o ID 15.000 e pensa: “A Empresa 15.000 mora no Servidor 2”. A requisição de gravação é enviada exclusivamente para o Servidor 2.
• Escalabilidade Infinita: O Servidor 1 e o Servidor 3 nem ficam sabendo dessa transação. Você acabou de dividir o uso de CPU, RAM e Disco por três. Se o SaaS continuar crescendo e vocês ganharem mais 10.000 empresas clientes, basta comprar um Servidor 4 (Shard D) e plugar na arquitetura.

Resumo do Impacto Prático

A implementação do particionamento geralmente é nativa e mais simples (bancos como PostgreSQL e MySQL fazem isso muito bem). Já o sharding adiciona uma camada de complexidade grande na engenharia, pois a sua aplicação precisa saber como rotear as informações.

Quando escolher qual?

A regra de ouro na arquitetura de dados é: Evite o Sharding até que ele seja absolutamente necessário.

Vá de Partitioning quando:

• Você tem tabelas gigantes (ex: logs, histórico financeiro) que estão deixando os relatórios lentos.
• Você precisa arquivar ou deletar dados antigos rapidamente (basta “dropar” a partição do mês passado, o que é instantâneo em comparação a deletar milhões de linhas).
• Seu hardware atual ainda tem capacidade de CPU e memória, o problema é apenas a organização do dado no disco.

Vá de Sharding quando:

• Você atingiu o limite de hardware. Fazer um upgrade no servidor atual custaria uma fortuna ou é fisicamente impossível.
• Sua aplicação tem uma carga massiva de gravação (Writes) que um único disco não consegue processar.
• Você precisa de distribuição geográfica (ex: guardar dados de europeus na Europa por questões de latência ou conformidade com a GDPR).

O Desafio do Sharding: O “Hotspot”

Um dos maiores riscos do Sharding é escolher a chave errada, criando um Hotspot (ponto quente). Por exemplo, se você dividir um banco de dados de uma rede social pela letra inicial do nome, o servidor responsável pela letra “A” e “M” receberá 80% do tráfego e vai travar, enquanto o servidor das letras “X”, “Y” e “Z” ficará ocioso. A distribuição precisa ser perfeitamente balanceada.

O post Sharding vs. Partitioning apareceu primeiro em Data Universe.