Views no SQLite: CREATE VIEW e INSTEAD OF

O que é uma view no SQLite

Uma view nada mais é do que um SELECT com nome. Depois de criar uma, você consulta ela como se fosse uma tabela comum — só que nada fica armazenado de fato. A cada vez que você lê de uma view, o SQLite executa a query original do zero.

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL,
    status TEXT
);

INSERT INTO orders (customer, amount, status) VALUES
    ('Ada', 120.00, 'paid'),
    ('Boris', 45.50, 'pending'),
    ('Rosa', 300.00, 'paid'),
    ('Boris', 80.00, 'paid');

CREATE VIEW paid_orders AS
SELECT customer, amount FROM orders WHERE status = 'paid';

SELECT * FROM paid_orders;

paid_orders parece e se comporta como uma tabela. Tem colunas, dá pra usar SELECT, dá pra fazer JOIN. Mas, por baixo dos panos, toda consulta é expandida para o filtro original WHERE status = 'paid'.

Esse é o modelo mental que importa: uma view é um apelido para uma consulta.

Por que usar views no SQLite

O maior ganho é dar nome às coisas. Uma consulta complicada ganha um nome curto e descritivo, e o resto do seu código continua legível:

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL,
    status TEXT
);

INSERT INTO orders (customer, amount, status) VALUES
    ('Ada', 120.00, 'paid'),
    ('Rosa', 300.00, 'paid'),
    ('Boris', 80.00, 'paid');

CREATE VIEW customer_totals AS
SELECT customer, SUM(amount) AS total, COUNT(*) AS order_count
FROM orders
WHERE status = 'paid'
GROUP BY customer;

SELECT * FROM customer_totals WHERE total > 100;

Sem a view, cada chamador teria que escrever o GROUP BY na mão — e qualquer um deles poderia errar o filtro. Com ela, a agregação fica definida em um único lugar. Os chamadores só precisam consultar customer_totals e aplicar os filtros adicionais que quiserem por cima.

Views também funcionam como uma espécie de fronteira de permissão. Se uma consulta não deve expor a coluna password_hash, crie uma view que selecione tudo menos essa coluna e faça o código da aplicação usar a view.

Sintaxe do CREATE VIEW no SQLite

A forma completa:

CREATE [TEMPORARY] VIEW [IF NOT EXISTS] view_name [(column_aliases)] AS
SELECT ...;

Algumas coisas que vale a pena saber:

• IF NOT EXISTS ignora a criação silenciosamente caso a view já exista.
• TEMPORARY (ou TEMP) cria uma view temporária que some quando a conexão é fechada.
• Os aliases de coluna entre parênteses permitem renomear as colunas da view sem mexer no SELECT original.

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price_cents INTEGER
);

INSERT INTO products (name, price_cents) VALUES
    ('Caderno', 450),
    ('Caneta', 200);

CREATE VIEW IF NOT EXISTS price_list (item, dollars) AS
SELECT name, price_cents / 100.0 FROM products;

SELECT * FROM price_list;

A view expõe nomes mais amigáveis (item, dollars) sem precisar renomear as colunas da tabela original.

Substituindo e removendo views no SQLite

O SQLite não tem CREATE OR REPLACE VIEW nem ALTER VIEW. Para alterar a definição de uma view, o jeito é remover e criar de novo:

CREATE TABLE orders (id INTEGER, status TEXT);
INSERT INTO orders VALUES (1, 'paid'), (2, 'pending');

CREATE VIEW active_orders AS
SELECT * FROM orders WHERE status = 'paid';

DROP VIEW active_orders;

CREATE VIEW active_orders AS
SELECT * FROM orders WHERE status IN ('paid', 'shipped');

SELECT * FROM active_orders;

DROP VIEW IF EXISTS active_orders; é a forma segura — não dá erro caso a view não exista. Apagar uma view nunca mexe nas tabelas subjacentes; você está removendo apenas a consulta salva.

Views temporárias no SQLite

Uma TEMP VIEW existe somente enquanto durar a conexão atual com o banco. Quando a conexão é encerrada, a view some junto. É útil em sessões de análise pontual, quando você não quer deixar definições espalhadas pelo banco:

CREATE TABLE events (
    id INTEGER PRIMARY KEY,
    type TEXT,
    occurred_at TEXT
);

INSERT INTO events (type, occurred_at) VALUES
    ('login', '2026-04-01'),
    ('purchase', '2026-04-01'),
    ('login', '2026-04-02');

CREATE TEMP VIEW today_logins AS
SELECT * FROM events WHERE type = 'login' AND occurred_at = '2026-04-02';

SELECT * FROM today_logins;

Views temporárias também são úteis pra "sombrear" o nome de uma consulta sem precisar gravar isso no schema — ótimo na hora de explorar dados.

Views no SQLite são read-only por padrão

Esse é o detalhe mais importante de todos. Não dá pra fazer INSERT, UPDATE nem DELETE direto em uma view:

sqlite> INSERT INTO paid_orders (customer, amount) VALUES ('Eve', 50);
Runtime error: cannot modify paid_orders because it is a view

A solução são as triggers INSTEAD OF. Você cria uma trigger que dispara no lugar da tentativa de escrita e traduz isso em uma operação real na tabela base:

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL,
    status TEXT
);

CREATE VIEW paid_orders AS
SELECT id, customer, amount FROM orders WHERE status = 'paid';

CREATE TRIGGER paid_orders_insert
INSTEAD OF INSERT ON paid_orders
BEGIN
    INSERT INTO orders (customer, amount, status)
    VALUES (NEW.customer, NEW.amount, 'paid');
END;

INSERT INTO paid_orders (customer, amount) VALUES ('Eve', 50.00);

SELECT * FROM orders;

A view continua sendo view — mas agora escrever nela tem para onde ir. A gente vê triggers com calma na próxima página.

Não existe materialized view no SQLite — faça na unha

Alguns bancos deixam você cachear o resultado de uma view em disco e atualizar quando quiser. O SQLite não tem isso. Toda leitura de uma view reexecuta a query por trás. Na maior parte dos casos isso nem incomoda — o SQLite é rápido e o planejador de queries é bom. Mas para agregações pesadas que você consulta muitas vezes, o jeito é criar uma tabela de verdade e manter ela sincronizada na mão:

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL
);

INSERT INTO orders (customer, amount) VALUES
    ('Ada', 120.00), ('Rosa', 300.00), ('Boris', 80.00);

CREATE TABLE customer_totals_cache AS
SELECT customer, SUM(amount) AS total
FROM orders
GROUP BY customer;

SELECT * FROM customer_totals_cache;

Você precisa atualizar esse cache em intervalos definidos, ou então configurar triggers na tabela orders para manter os dados em dia. Dá trabalho braçal — mas é a única alternativa no SQLite.

Listando views no SQLite

Os metadados das views ficam guardados em sqlite_master, no mesmo lugar das tabelas e dos índices:

CREATE TABLE t (x INTEGER);
CREATE VIEW v1 AS SELECT * FROM t;
CREATE VIEW v2 AS SELECT x * 2 AS doubled FROM t;

SELECT name, sql FROM sqlite_master WHERE type = 'view';

A coluna sql devolve o CREATE VIEW original — ótimo pra quando você esqueceu o que uma view faz. No CLI, o comando .schema nome_da_view mostra a mesma coisa de forma mais limpa.

Quando usar uma view no SQLite

As views valem a pena quando:

• Uma consulta não-trivial aparece repetida em três ou mais lugares. Dar um nome a ela uma vez é melhor do que ficar copiando e colando.
• Você quer expor um recorte específico de colunas ou linhas para uma parte da aplicação.
• Uma agregação representa conceitualmente uma única coisa (monthly_sales, active_users) que faz sentido o consumidor tratar como um substantivo.

Pule a view quando:

• A consulta é usada em um único lugar. Coloca ela inline e pronto.
• Performance é crítica e a consulta por trás é cara — esse custo é pago a cada leitura. Nesses casos, é melhor materializar o resultado numa tabela real.
• A view depende de outra view, que depende de outra view. O SQLite lida bem com esse aninhamento, mas uma cadeia de três ou quatro views torna o SQL real difícil de seguir na hora de debugar.

A seguir: triggers

Views e triggers costumam andar juntas — o padrão INSTEAD OF, que torna uma view gravável, é justamente uma das razões principais para os triggers existirem. Mas os triggers também brilham sozinhos: auditoria, cascateamento de updates e garantia de invariantes. É o assunto da próxima página.