SQL: Views

Introdução

Uma view é uma consulta salva com nome — ela não armazena dados fisicamente (na maioria dos casos), apenas guarda a definição de um SELECT. Toda vez que você consulta a view, o banco executa a query por trás dela e devolve o resultado como se fosse uma tabela.

CREATE VIEW clientes_ativos AS
SELECT id, nome, email FROM clientes WHERE status = 'ativo';

-- Depois, você consulta como se fosse uma tabela normal:
SELECT * FROM clientes_ativos WHERE nome LIKE 'A%';

Pense na view como um "apelido inteligente" para uma query complexa. Em vez de reescrever um JOIN de 4 tabelas toda vez, você cria a view uma vez e reutiliza SELECT * FROM minha_view.

Por que usar views (motivação real)

1. Simplificação: esconder a complexidade de JOINs/subqueries repetitivos atrás de um nome simples.
2. Segurança: dar acesso a uma view que expõe só algumas colunas (ex: sem salário, sem CPF), sem dar acesso à tabela real.
3. Abstração/desacoplamento: se a estrutura das tabelas mudar, você ajusta só a view, e as queries que a usam continuam funcionando sem alteração.
4. Reuso: centralizar lógica de negócio (ex: "o que conta como pedido válido") em um único lugar, em vez de repetir o mesmo WHERE em 10 queries diferentes.
5. Legibilidade: transformar um relatório complicado em algo que qualquer pessoa entende: SELECT * FROM vendas_por_mes.

Criando Views

Sintaxe básica

CREATE VIEW nome_da_view AS
SELECT coluna1, coluna2, ...
FROM tabela
WHERE condicao;

Exemplo simples

CREATE VIEW produtos_em_estoque AS
SELECT id, nome, preco, quantidade
FROM produtos
WHERE quantidade > 0;

Agora, em vez de repetir WHERE quantidade > 0 toda vez, qualquer pessoa faz:

SELECT * FROM produtos_em_estoque ORDER BY preco DESC;

Exemplo com JOIN (caso mais comum no mundo real)

Views brilham quando escondem a complexidade de múltiplas tabelas relacionadas:

CREATE VIEW pedidos_detalhados AS
SELECT 
  p.id AS pedido_id,
  c.nome AS cliente,
  pr.nome AS produto,
  p.quantidade,
  p.quantidade * pr.preco AS total,
  p.data_pedido
FROM pedidos p
JOIN clientes c ON p.cliente_id = c.id
JOIN produtos pr ON p.produto_id = pr.id;

Sem a view, toda vez que alguém quisesse ver um pedido "completo" (com nome do cliente e do produto, não só os IDs), precisaria escrever esse JOIN triplo de novo. Com a view:

SELECT * FROM pedidos_detalhados WHERE cliente = 'Maria Silva';

Modificando Views

Existem duas abordagens, dependendo do banco:

Abordagem 1: CREATE OR REPLACE VIEW (PostgreSQL, MySQL, Oracle)

Substitui a definição inteira da view de uma vez:

CREATE OR REPLACE VIEW produtos_em_estoque AS
SELECT id, nome, preco, quantidade, categoria
FROM produtos
WHERE quantidade > 0;

Regra importante: CREATE OR REPLACE normalmente só permite adicionar colunas no final, ou mudar a lógica do WHERE/JOIN — você não pode remover uma coluna ou mudar a ordem das colunas existentes sem dar DROP na view primeiro. Se tentar, o banco geralmente recusa com um erro.

Abordagem 2: ALTER VIEW (SQL Server, também existe em outros)

ALTER VIEW produtos_em_estoque AS
SELECT id, nome, preco, quantidade, categoria
FROM produtos
WHERE quantidade > 0;

Funciona de forma equivalente ao CREATE OR REPLACE, mas é a sintaxe usada no SQL Server (que não aceita CREATE OR REPLACE VIEW — lá, CREATE VIEW falha se a view já existir, e você precisa usar ALTER VIEW para modificar uma existente).

Por que "substituir" em vez de “editar campo por campo”?

Views não têm um equivalente ao ALTER TABLE ADD COLUMN — você não "adiciona uma coluna" a uma view incrementalmente. Você reescreve a query inteira com CREATE OR REPLACE/ALTER VIEW. Isso é diferente de tabelas, e costuma confundir quem vem de ALTER TABLE.

O que acontece com permissões e dependências ao modificar

• Modificar uma view preserva as permissões (GRANT) já concedidas a ela na maioria dos bancos — não precisa re-conceder acesso.
• Se outras views dependem da view que você está alterando (lembra do exemplo vendas_por_mes em cima de pedidos_detalhados?), mudar a view de baixo pode quebrar as views de cima se você remover uma coluna que elas usam. Vale sempre mapear as dependências antes de alterar uma view "de base".