CREATE VIEW: Creating Virtual Tables with Query Results in SQL

A view is a saved SELECT statement that you can query as if it were a table. It stores no data of its own — it’s a name pointing at a query. Every time you read from the view, the database runs the underlying SELECT against the current data. Views are how you hide a gnarly join behind a clean name, expose only certain columns, and keep one definition of “what an active customer is” instead of pasting the same WHERE clause everywhere.

The playground below runs real SQL in your browser and understands CREATE VIEW. Run it as written — it defines a view, then queries it:

The basic syntax

CREATE VIEW view_name AS
SELECT column1, column2
FROM table_name
WHERE condition;

You give the view a name and hand it a SELECT. From then on, SELECT * FROM view_name runs that query. The columns of the view are whatever the SELECT returns (including any aliases). Run the first example above and notice you can GROUP BY the view just like a real table — because to the rest of your SQL, it is one.

Why views are worth it

• Simplify complex queries. Wrap a multi-table join or a nested aggregate once; everyone else queries a simple name.
• Restrict access. Grant people the view (say, orders without the customer’s email) instead of the raw table — a layer of security.
• One source of truth. Define “active customer” or “monthly revenue” once. Fix the logic in the view and every report that uses it is fixed too.

Here’s the payoff — a view that hides an aggregate behind a friendly name:

Anyone querying category_sales never has to know there’s a GROUP BY underneath — and if the definition of revenue changes, you edit it in one place.

Views don’t store data

This is the key mental model: a view holds no rows. It’s a query with a name. When the underlying tables change, the view reflects the new data the next time you read it — there’s nothing to refresh. (The exception is a materialized view, which does cache results and must be refreshed; that’s a different feature with a different trade-off.)

Replacing and dropping views

To change a view’s definition, use CREATE OR REPLACE VIEW. To remove it entirely, DROP VIEW:

CREATE OR REPLACE VIEW view_name AS
SELECT ...;   -- redefine

DROP VIEW view_name;   -- remove

Dialect note: CREATE OR REPLACE VIEW works in PostgreSQL, MySQL, and Oracle. SQL Server uses CREATE OR ALTER VIEW, and SQLite has neither — there you DROP VIEW and create it again. Also note that replacing a view usually can’t change or reorder its existing columns; if that’s what you need, drop and recreate.

Run the “Drop the view” example and then try to query it — the view is gone, so the query errors, exactly as it would in a real database.

Practice

Frequently asked questions

What is a view in SQL? A named, saved SELECT statement. You query it like a table, but it stores no data — it runs its underlying query against the current data each time.

Does a view store data? No. A regular view is just a saved query. A materialized view is the exception — it caches the result and has to be refreshed.

How do I change a view? CREATE OR REPLACE VIEW view_name AS SELECT ... redefines it in place. DROP VIEW view_name removes it.

Can a view join tables or use aggregates? Yes — a view can wrap any SELECT, including joins, GROUP BY, and even other views. That’s the point: hide complexity behind a simple name.

Can I update data through a view? Sometimes. Simple single-table views are often updatable; views with joins, aggregates, or DISTINCT usually are not. Rules vary by database.

From saved queries to shipped pipelines

A view saves a query inside one database. When “the query” needs to run across many sources and land somewhere on a schedule, that’s a pipeline — and ET1 is the visual, asynchronous ETL tool for it: the filter, join, and aggregate you’d bury in a view become labeled nodes on a canvas, with a live preview at each step.

Keep going: the SELECT statement a view wraps, filtering with the WHERE clause, joins, and GROUP BY.