Vistas en SQLite: CREATE VIEW e INSTEAD OF

Una vista es una consulta guardada

Una vista en SQLite no es más que una sentencia SELECT con un nombre. Una vez creada, puedes consultarla como si fuera una tabla, aunque en realidad no se guarda ningún dato. Cada vez que lees de una vista, SQLite vuelve a ejecutar la consulta original desde cero.

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 se ve y se comporta como una tabla. Tiene columnas, puedes hacer SELECT sobre ella y también puedes hacer joins. Pero por debajo, cada consulta se expande al filtro original WHERE status = 'paid'.

Ese es el modelo mental completo: una vista es un alias para una consulta.

Para qué sirven las vistas en SQLite

La gran ventaja es ponerle nombre a las cosas. Una consulta complicada recibe un nombre corto y descriptivo, y el resto de tu código se mantiene legible:

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;

Sin la vista, cada quien tendría que escribir su propio GROUP BY — y cualquiera podría equivocarse al aplicar el filtro. Con la vista, la agregación queda definida en un solo sitio. Quien la consulta simplemente pide customer_totals y añade encima los filtros adicionales que necesite.

Las vistas también sirven como una especie de frontera de permisos. Si una consulta no debería exponer la columna password_hash, basta con crear una vista que seleccione todo excepto esa columna y hacer que el código de la aplicación use la vista.

Sintaxis de CREATE VIEW en SQLite

La forma completa:

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

Algunos detalles que conviene tener presentes:

• IF NOT EXISTS evita crear la vista si ya existe, y lo hace sin lanzar ningún error.
• TEMPORARY (o TEMP) crea una vista temporal que desaparece al cerrar la conexión.
• Los alias de columnas entre paréntesis te permiten renombrar las columnas de la vista sin tocar el SELECT original.

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

INSERT INTO products (name, price_cents) VALUES
    ('Cuaderno', 450),
    ('Bolígrafo', 200);

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

SELECT * FROM price_list;

La vista expone nombres más amigables (item, dollars) sin tener que renombrar columnas en la tabla original.

Reemplazar y eliminar vistas en SQLite

SQLite no admite CREATE OR REPLACE VIEW ni ALTER VIEW. Si quieres modificar la definición de una vista, tendrás que eliminarla y volver a crearla:

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; es la forma segura: no lanza error si la vista no existe. Eliminar una vista nunca afecta a las tablas subyacentes; solo estás borrando la consulta guardada.

Vistas temporales en SQLite

Una TEMP VIEW solo existe durante la conexión actual a la base de datos. Al cerrar la conexión, la vista desaparece. Resulta muy útil para sesiones de análisis puntuales en las que no quieres dejar definiciones rastreables:

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;

Las vistas temporales también te permiten "ensombrecer" el nombre de una consulta sin tener que dejarlo plasmado en tu esquema, algo muy útil cuando estás explorando.

Las vistas en SQLite son de solo lectura por defecto

Esta es la trampa más importante a tener en cuenta. No puedes hacer INSERT, UPDATE ni DELETE directamente sobre una vista:

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

La solución son los triggers INSTEAD OF. Lo que haces es escribir un trigger que se dispara en lugar de la operación de escritura y la traduce a una operación real sobre la tabla subyacente:

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;

La vista sigue siendo una vista, pero ahora las escrituras tienen a dónde ir. Veremos los triggers a fondo en la siguiente página.

Sin vistas materializadas: hazlas tú mismo

Algunas bases de datos permiten cachear en disco el resultado de una vista y refrescarlo cuando haga falta. SQLite no. Cada lectura sobre una vista vuelve a ejecutar la consulta original. Para la mayoría de los casos esto no es problema: SQLite es rápido y su planificador de consultas funciona muy bien. Pero si tienes agregaciones costosas que se consultan muchas veces, lo mejor es crear una tabla real y mantenerla sincronizada a mano, simulando una vista materializada en SQLite:

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;

Después actualizarías esa caché con una tarea programada, o engancharías triggers sobre orders para mantenerla al día. Es trabajo manual, sí, pero en SQLite no hay otra alternativa.

Cómo listar vistas en SQLite

Los metadatos de las vistas viven en sqlite_master, junto con las tablas y los í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';

La columna sql te devuelve la sentencia CREATE VIEW original — muy útil cuando ya no te acuerdas de qué hace una vista. Desde la CLI, .schema view_name muestra lo mismo, pero más limpio.

Cuándo conviene usar una vista en SQLite

Las vistas valen la pena cuando:

• Una consulta no trivial se repite en tres o más sitios. Mejor ponerle un nombre una vez que andar copiando y pegando.
• Quieres exponer un subconjunto concreto de columnas o filas a cierta parte de la aplicación.
• Una agregación es, conceptualmente, una sola cosa (monthly_sales, active_users) que quien la consume debería tratar como un sustantivo.

Olvídate de la vista cuando:

• La consulta se usa en un único sitio. Métela en línea y listo.
• El rendimiento importa y la consulta subyacente es cara — vas a pagar ese coste en cada lectura. Mejor cachea el resultado en una tabla real.
• La vista depende de otra vista, que a su vez depende de otra. SQLite maneja bien el anidamiento, pero una cadena de tres o cuatro vistas vuelve el SQL real muy difícil de seguir cuando estás depurando.

Siguiente paso: los triggers

Las vistas y los triggers suelen ir de la mano — el patrón INSTEAD OF, que es lo que permite escribir sobre una vista, es justamente una de las razones principales por las que existen los triggers. Pero los triggers también dan mucho juego por sí solos: logs de auditoría, actualizaciones en cascada y para forzar invariantes. De eso va la siguiente página.