Views

The exam office needs to see grades. They must not see fee balances — that's in the same Student table.

You could write them a careful query and hope they never edit it. Or you could hand them a window that only shows what they're allowed to see.

Why & what

You already met the idea in 1.3 without the name: the external level, where each user sees only their own slice of the database. A view is how you actually build that slice.

A view is a saved query with a name. It stores no rows of its own — every time you read it, its query runs again on the real tables underneath.

How it works

1. Write the query you want people to have. Join Student and Enrollment, select name, course, grade — and simply don't include fees_due.
2. Save it with a name.

CREATE VIEW student_grades AS
SELECT s.name, e.course, e.grade
FROM Student s
JOIN Enrollment e ON s.roll_no = e.roll_no;

3. Use it like a table. SELECT * FROM student_grades WHERE grade = 'A' works exactly as if it were one. That's the whole appeal — the join is hidden inside.
4. Notice what's not there. fees_due is unreachable through this view. Give the office access to the view instead of the table, and the money column is invisible to them.
5. Watch it stay current. Update a grade in Enrollment and the view shows the new value immediately — because it holds no copy. It re-runs its query each time you read it.

Notice: a view stores no rows — it re-runs its query every time you read it.

Common confusion

The big one: people think a view stores data. It doesn't. It's a saved query, so it costs storage of essentially nothing and costs query time every read.

The exception worth naming: a materialized view does store the result physically. It's fast to read but goes stale until it's refreshed. Normal view = always fresh, re-computed. Materialized view = fast, possibly stale.

Second: can you update through a view? Sometimes. A simple view over one table usually accepts updates. A view with joins, GROUP BY, or DISTINCT usually doesn't — because the database can't work out which underlying row you meant to change.

Interview angle

1. "What is a view and why use one?" — A saved query used like a table. Reasons: hide sensitive columns, hide complex joins, and give different users different slices.
2. "Does a view store data?" — No, it re-runs its query each time. A materialized view does store results, trading freshness for speed.
3. "Can you INSERT or UPDATE through a view?" — Simple single-table views, usually yes. Views with joins or aggregates, usually no, because the target row is ambiguous.

Quiz: skipped — reinforced above.

Recap

A view is a named saved query that stores no rows — it hides columns and complexity, always reflects the current data, and only a materialized view actually stores results.