Views

Some queries are needed again and again: the manager wants the totals of the orders every week, and support keeps looking for the games that are out. A view gives a query a name, and then you can use it as if it were a table:

CREATE VIEW released_games AS
SELECT title, genre, price
FROM games
WHERE released IS NOT NULL;

After CREATE VIEW, the name and AS comes an ordinary SELECT. The view is then queried like any table, with WHERE, ORDER BY, joins and all:

SELECT title, price
FROM released_games
WHERE genre = 'Action'
ORDER BY price;

A view holds no rows of its own. It keeps only the query, and the database runs it whenever you use the view. So a view always shows the current data: when Robot Rebellion gets its release date, it appears among the released games, and nobody has to change the view:

UPDATE games
SET released = '2026-02-27'
WHERE id = 18;

SELECT title, price
FROM released_games
WHERE genre = 'Action'
ORDER BY price;

Views are handy for long queries with joins and groups, which others can then use without knowing how they work, and for calculations that should be done the same way everywhere. A view can also leave out columns that some people shouldn't see. The columns of a view are named as in its SELECT.

You can only read a view: INSERT, UPDATE and DELETE on it fail with cannot modify released_games because it is a view. The data is changed in the tables the view reads. A view you no longer need is deleted with DROP VIEW released_games;, and a view you want to change, you delete and create again. Like the tables you create, views don't appear in the Tables tab.

Typical mistake: a calculated column without an alias. In a view made of SELECT genre, SUM(price) FROM games GROUP BY genre, the second column is called SUM(price), which is awkward to use in queries on the view. With SUM(price) AS total, it's simply total.