SQL Views
A view gives a saved query a name. It can keep repeated reporting logic in one place and expose a simpler set of columns. An ordinary view reads underlying data when queried; it is not a frozen copy.
Understand the idea
The paid_orders view centralises a status condition. A later query can treat it much like a table in FROM. A view does not automatically make a query faster, and it should not be assumed to be a complete security boundary across engines. Permissions and update support depend on the database.
Where to try it
Run this example in the SQL playground. The lesson link loads the shop tables and sample rows before this query. Select Run when you are ready. Every run starts fresh, so your changes do not affect the website or a previous run.
SQLite sample data · MySQL / MariaDB sample data · See the sample tables
A worked example
CREATE VIEW paid_orders AS
SELECT order_id, customer_id, total_cents
FROM orders WHERE status = 'paid';
SELECT order_id, total_cents
FROM paid_orders ORDER BY order_id;
Read the result
The view returns orders 101 and 102. It stores the query definition, not a separate permanent copy of those two rows in this ordinary-view example.
Try one change
Insert a new paid order in a disposable run and query the view again. Compare that behaviour with a CREATE TABLE AS snapshot.