What Is a View in SQL?

A view is a named query. When you reference it, the database runs the query it stands for and returns the result as though it were a table. Nothing is stored: the view holds SQL, not data.

CREATE TABLE customers (
  id INTEGER PRIMARY KEY,
  name VARCHAR(120) NOT NULL,
  city VARCHAR(80) NOT NULL
);

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  status VARCHAR(20) NOT NULL
);

INSERT INTO customers (id, name, city) VALUES
  (1, 'Ada Lovelace', 'London'),
  (2, 'Grace Hopper', 'New York'),
  (3, 'Alan Turing',  'London');

INSERT INTO orders (id, customer_id, amount, status) VALUES
  (1, 1, 120.00, 'shipped'),
  (2, 1, 340.50, 'pending'),
  (3, 2,  75.25, 'shipped');

CREATE VIEW customer_summary AS
SELECT c.id AS customer_id,
       c.name AS customer_name,
       c.city,
       COUNT(o.id) AS order_count,
       ROUND(COALESCE(SUM(o.amount), 0), 2) AS total_spend
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.id, c.name, c.city;

SELECT customer_id, customer_name, city, order_count, total_spend
FROM customer_summary
ORDER BY customer_id;

Three rows come back, each with the customer's details and their order totals already worked out. Alan Turing shows 0 orders and a total of 0.00, because the LEFT JOIN kept him in the result and the COALESCE turned his NULL sum into a zero.

Four reasons to create one. To name a piece of business logic once and reuse it, so the definition of "customer spend" lives in one place. To hide the shape of the tables from the consumers of a report, so a change to the schema does not break every query that reads it. To give a stable interface to a set of tables that several teams read. And to express a permission boundary — a view that exposes three columns of a table can be granted to a reporting user without granting them the table.

Two limitations to remember. A view is not a materialised result, so a query against a view over a large table costs exactly what the underlying query would have cost — with one caveat, that some engines will refuse to push a predicate from the outer query into the view, which can make a view slower than writing the query inline. And a view that aggregates cannot generally be updated through.

A view over three tables is where the abstraction starts to pay, because the query against it reads like a single relation even though it spans customers, orders, order lines and products.

CREATE TABLE customers (
  id INTEGER PRIMARY KEY,
  name VARCHAR(120) NOT NULL
);

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL,
  placed_on TEXT NOT NULL
);

CREATE TABLE products (
  id INTEGER PRIMARY KEY,
  name VARCHAR(120) NOT NULL,
  price_cents INTEGER NOT NULL
);

CREATE TABLE order_lines (
  id INTEGER PRIMARY KEY,
  order_id INTEGER NOT NULL,
  product_id INTEGER NOT NULL,
  qty INTEGER NOT NULL
);

INSERT INTO customers (id, name) VALUES (1, 'Ada Lovelace');
INSERT INTO orders (id, customer_id, placed_on) VALUES (1, 1, '2026-03-01');
INSERT INTO products (id, name, price_cents) VALUES
  (1, 'Mechanical Keyboard', 7950),
  (2, 'USB-C Hub', 3200);
INSERT INTO order_lines (id, order_id, product_id, qty) VALUES
  (1, 1, 1, 1),
  (2, 1, 2, 2);

CREATE VIEW order_detail AS
SELECT c.name AS customer_name,
       o.id AS order_id,
       p.name AS product_name,
       ol.qty,
       ROUND(ol.qty * p.price_cents / 100.0, 2) AS line_total
FROM order_lines AS ol
JOIN orders AS o ON o.id = ol.order_id
JOIN customers AS c ON c.id = o.customer_id
JOIN products AS p ON p.id = ol.product_id;

SELECT * FROM order_detail ORDER BY order_id, product_name;

Two rows come back: Ada Lovelace's order 1 with the Mechanical Keyboard at 79.50 and the USB-C Hub at 64.00. The query that produced them reads four tables, and the caller who selects from the view sees a flat result with sensible column names.

The behaviour that matters is what happens when the underlying data changes. Because a view stores SQL rather than results, the next query against the view reflects the current state of the tables — if you change a product's price and query the view again, the line total changes with it. Nothing has to be refreshed, and nothing can go stale.

The trade-off is cost. Every read of the view runs the whole query, including the joins and the arithmetic. On a large table that is a real price, and a view that joins four tables in a reporting tool can be noticeably slower than the equivalent hand-written query. Some engines will flatten a simple view into the outer query and then push predicates down into it; others treat the view as a barrier and do not, which is the case where a view can be slower than writing the join yourself.

A view stores no data at all. It stores a query definition, and the engine evaluates that query every time you reference the view. The result is computed fresh, which is why a view never goes stale and never needs refreshing.

That has a set of consequences worth being able to state. The query against a view costs the same as running the underlying query directly, so a view over a large table is not free. The view's definition is resolved when you create it, so if you rename or drop a column it depends on, the view may become invalid — in SQLite, renaming a column that a view references will actually update the view's stored SQL, but in other engines the view can be left dangling and fail when queried. And a view created without the CHECK OPTION clause can, in some engines, be a route to updating the base tables through a filter, which is occasionally a security problem.

This is exactly the difference from a materialised view, which does store the result of the query. A materialised view is a snapshot: it has a stored copy of the data, it has to be refreshed explicitly or on a schedule, and reading from it is fast because there is nothing to compute. A regular view is always current and always costs the same as the underlying query.

So the choice between them is freshness against speed. If the data must be current at the moment you read it, use a regular view. If the data can be a few minutes old and the read happens thousands of times a second, use a materialised view or a summary table.