CREATE VIEW saves a SELECT statement as a virtual table, letting you query complex joins through a simple object.
CREATE VIEW stores a SELECT statement under a name. The view behaves like a read-only virtual table, recalculating on each access. It reduces duplicate logic, shortens queries, and masks sensitive data.
Use CREATE [ OR REPLACE ] [ TEMP ] VIEW view_name [ (col1, …) ] AS select_query [ WITH [ CASCADED | LOCAL ] CHECK OPTION ];
. Add TEMP
for session-only views, supply column aliases when the SELECT uses expressions, and append WITH CHECK OPTION
to block rows that violate the view filter on INSERT/UPDATE.
Create views for repetitive reports—customer lifetime value, daily revenue, or low-stock products. Stakeholders query one object instead of rewriting joins between Customers
, Orders
, OrderItems
, and Products
.
Yes. Grant SELECT
on the view to analysts while withholding table permissions. The view surfaces only approved columns, perfect for exposing order summaries without customer emails.
Run CREATE OR REPLACE VIEW
to update the definition without breaking dependent queries. Remove it with DROP VIEW IF EXISTS view_name;
to avoid errors if the view is already gone.
1) Name views with a noun phrase like daily_revenue
.
2) Avoid SELECT *
; list columns to prevent accidental schema leaks.
3) Add comments using COMMENT ON VIEW
for discoverability.
Ambiguous column names break consumers—always alias expressions. Forgetting OR REPLACE
blocks deployments; include it when views may already exist.
No. A standard view recalculates each time you query it. Use MATERIALIZED VIEW if you need persisted data.
You can if the SELECT targets a single base table and omits aggregates. Add WITH CHECK OPTION to enforce the view filter on writes.
GRANT SELECT ON view_name TO analyst_role; REVOKE ALL ON underlying tables FROM analyst_role; The role now sees only the view.