Theory
Show them the prices, not the profit
Meera's sales table has a cost price column, her secret buying price. Her counter staff need to see selling prices to bill customers, but must never see the cost.
She cannot let them query the whole table. But copying selected columns into a new table would mean maintaining two copies that drift apart.
The elegant answer is a view: a saved query that acts like a table but stores no data, showing only the columns she chooses, always live. This last topic ties the whole subject together: the view is a query wearing a table's clothes.
Theory
A window, not a room
A table is a room full of furniture, the actual stored data. A view is a window into that room, framed to show only part of it. The window holds no furniture of its own; it just shows what is in the real room, framed your way. Move the furniture (change the data) and the window shows the change instantly. Broaden or narrow the frame without ever duplicating a single chair.
Practical
A view that hides the cost price
-- A saved query: item + selling price only, cost hidden
CREATE VIEW public_prices AS
SELECT item, price
FROM sales
WHERE category <> 'Confidential';
-- Staff query the view exactly like a table
SELECT * FROM public_prices;
-- They see item and price, never the cost column
-- Remove the view (the sales table is untouched)
DROP VIEW public_prices;This example runs in Gri-Learn on the web, where you can edit it and see the output.
Theory
View vs table: the key difference
The exam's core question: how does a view differ from a table?
- A table physically stores data on disk.
- A view stores only the SELECT query, no data of its own. Each time you use it, it runs the query live against the base tables.
So a view is always current (it reflects the latest base-table data automatically), costs almost no storage, and can simplify a complex query (save it once, reuse by name) or provide security (expose only safe columns). Simple views are updatable; views with joins or aggregates are usually read-only.
Quiz
Meera updates a price in the sales TABLE. Does her public_prices VIEW show the new price, and why?
- Yes, a view stores no data of its own; it runs its query live against the base table each time
- No, the view keeps its own frozen copy of the data
- Only if she rebuilds the view manually
- No, views cannot show prices
Show the answer
Yes, a view stores no data of its own; it runs its query live against the base table each time
A view holds no data, only the stored SELECT. Every time it is used it re-runs against the live base table, so any change in sales appears in public_prices instantly, no rebuild needed. This 'always current, stores no data' property is the defining difference from a table, and the most-asked view exam point.
Think first
Why not just make a second table?
Meera could copy item and price into a new TABLE instead of a view. Give two reasons a view is better for her hide-the-cost goal.
Show the answer
One: it never goes stale. A copied table would freeze the prices at copy time and drift out of date; a view is always live. Two: no duplicate storage or double maintenance. A view stores only the query (near-zero space), while a second table duplicates data she must keep in sync. Plus security: the view exposes only safe columns while the real cost stays protected in the base table. Live, lean, and secure, that is why views exist.
Watch out
Where marks leak
Saying a view stores data, it stores only the query (a table stores data; a view stores a SELECT). Thinking a view can go stale, it is always live. Forgetting that DROP VIEW removes only the view, the base table's data is untouched. And that complex views (joins, aggregates, GROUP BY) are typically read-only, only simple views are updatable. The view-vs-table distinction is guaranteed marks if stated precisely.
Formula
The subject, complete
Trace the whole journey: Meera's overloaded spreadsheet (Unit 1-2) forced the move to a database (Unit 3), which she now queries fluently in SQL (Unit 4), views and all. You can build a table, constrain it, fill it, query it, summarise it, and secure it with views. That is genuine, employable database skill. Databases power every app you will ever build, including the one you are reading this on. You have finished BCA105.
Summary
Key takeaways
- A view is a virtual table defined by a stored SELECT query; it holds NO data of its own.
- It runs live against the base tables each time, so it always shows current data.
- Uses: simplify complex queries (save and reuse), and security (expose only chosen columns/rows).
- Table stores data physically; view stores only the query (the key difference).
- Simple views are updatable; views with joins/aggregates are usually read-only. DROP VIEW removes only the view.
- Memory hook: a view is a window into the data room, not a room of its own.