Course topics

By WebNest Studio Engineering Team

Database and SQL Tutorial

SQL Views

A view is a stored, named SQL query that behaves like a virtual table: you can SELECT from it just like a real table, but it has no data of its own — every time it is queried, the database runs the underlying query fresh against the real, underlying tables. Views are a way to package a complex or frequently repeated query behind a simple, reusable name.

Why it matters

A view is a saved query that can be used like a table. It lets a complicated join be written once and reused by name, and it lets you give someone access to part of a table, hiding columns such as password hashes or salaries. Reporting tools and permission schemes rely on views heavily.

Creating and Using a View

CREATE VIEW view_name AS SELECT ... defines a view. Once created, it can be queried exactly like a table: SELECT * FROM view_name. Because a view is just a saved query definition, it always reflects the current state of the underlying tables — it is never "stale" the way a manually copied table would be.

Simplifying Complex Queries

A view is especially useful when several parts of an application repeatedly need the same complicated join or aggregation. Instead of duplicating a ten-line query with multiple joins in every report and every application module, that logic is written once inside a view, and every consumer simply selects from the view by name — improving both consistency and maintainability.

Restricting Access with Views

A view can also expose only a subset of columns or rows from an underlying table, which is a common way to restrict what certain users or applications can see. For example, a view over an employees table might omit the salary column entirely, so that users granted access only to the view can never see compensation data, even though the full data still exists in the underlying table.

Example

Creating a view that hides sensitive columns and simplifies a join

SQL
CREATE VIEW employee_directory AS
SELECT e.id, e.name, e.department, d.location
FROM employees e
JOIN departments d ON d.name = e.department;

SELECT * FROM employee_directory WHERE department = 'Engineering';
Output
Returns 2 rows: (1, 'Asha Rao', 'Engineering', 'Bangalore'), (3, 'Meera Iyer', 'Engineering', 'Bangalore') — salary is never exposed, since it is not selected in the view.

Common Mistakes

  • Assuming a view stores a physical copy of data — a standard (non-materialized) view re-runs its underlying query on every access and always reflects live data.
  • Expecting a view to speed up a slow query automatically — a plain view does not cache results; a separate materialized view is needed for that, and it must be refreshed to stay current.
  • Building deeply nested views (views selecting from other views selecting from other views) that become difficult to reason about and slow to query.
  • Relying on a view alone for security without also setting proper database permissions — a user with direct access to the underlying tables can bypass the view entirely.

Exercise

Create a view named active_users that shows only the id and name of users whose active flag is true, leaving out the password column. Then select the names from the view.

Expected output: name then Asha

SQL · starter code
CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, password_hash TEXT, active BOOLEAN);
INSERT INTO users (id, name, password_hash, active) VALUES
  (1, 'Asha', 'x9f2', TRUE),
  (2, 'Ravi', 'k3p8', FALSE);

-- TODO: create the view active_users (id and name of active users)

-- TODO: select the names from the view
Show hints
  • The syntax is CREATE VIEW name AS SELECT ....
  • A view is queried exactly like a table: SELECT name FROM active_users.
Show solution
SQL · solution
CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, password_hash TEXT, active BOOLEAN);
INSERT INTO users (id, name, password_hash, active) VALUES
  (1, 'Asha', 'x9f2', TRUE),
  (2, 'Ravi', 'k3p8', FALSE);

CREATE VIEW active_users AS
SELECT id, name
FROM users
WHERE active = TRUE;

SELECT name FROM active_users;

Quick quiz

1. Does an ordinary view store its own copy of the data?

  • A. Yes, it is a snapshot
  • B. Yes, but only the first 1,000 rows
  • C. No; it stores only the query, which runs each time the view is used
  • D. Only if the table has an index
Show answer

C. A materialized view is the kind that stores the result.

2. How can a view improve security?

  • A. It encrypts the table
  • B. Users can be given access to the view, which exposes only chosen columns and rows, and not to the underlying table
  • C. It hides the database from the network
  • D. It disables SELECT
Show answer

B. The view acts as a restricted window onto the data.

3. A row is added to the underlying table. What does the view show next time it is queried?

  • A. The new row, if it meets the view's conditions
  • B. The old data until the view is recreated
  • C. An error
  • D. Nothing
Show answer

A. The view's query runs against the current data.

Interview questions

What is a view and why use one?

Show answer

A view is a named query stored in the database that behaves like a virtual table. It simplifies complex queries by hiding joins and calculations behind a name, gives applications a stable interface even when the underlying tables change, and restricts access by exposing only certain columns or rows. It stores no data of its own, so it always reflects the current contents of its tables.

What is the difference between a view and a materialized view?

Show answer

An ordinary view runs its query every time it is used, so it is always up to date and costs as much as the query does. A materialized view stores the result physically, so reading it is fast, but the data is as old as the last refresh and must be refreshed explicitly or on a schedule. Materialized views suit expensive aggregations over data that does not need to be current to the second.

Key Points to Remember

  • A view is a saved, named SELECT query that can be queried like a virtual table, with no data of its own.
  • Views simplify repeated complex joins or aggregations by giving them a single reusable name.
  • Views can restrict access by exposing only specific columns or rows from underlying tables.
  • A standard view always reflects live data because it re-executes its query on every access; it is not a cached copy.

Practice in the playground

Write and run your own code for this topic, or start from the exercise or an example. Runs your SQL on SQLite in your browser. Standard SQL works; a few features that exist only in PostgreSQL or MySQL do not. Your code for each topic is kept in this browser.

Run the examples

Change an input, predict the result, then compare it with the output. Explain why the result changes.

These examples need a project environment on your computer, so they can be copied but not run here. Codelab runs Python, FastAPI backends with SQLite, plain Java 17 and HTML/CSS/JavaScript.

WebNest Studio

Written by

WebNest Studio Engineering Team

Practical lessons from developers working with Java, Python, React, databases and production systems.

Led by Vansh Duggal, Founder, WebNest Studio · Full-stack & software engineering