CREATE VIEW saves a SELECT statement as a virtual table, letting you query complex logic with a simple object name.
Views let you wrap complex joins and calculations into a reusable object, shield raw tables, simplify analyst SQL, and adjust logic without touching dashboards.
Use CREATE VIEW view_name AS SELECT … . Add OR REPLACE to update safely. WITH NO SCHEMA BINDING allows underlying table changes.
CREATE OR REPLACE VIEW paid_orders AS
SELECT id, customer_id, total_amount
FROM Orders
WHERE total_amount > 0;
Write any valid SELECT. Redshift stores only the SQL, so each query hits current data.
CREATE VIEW customer_order_totals AS
SELECT c.id, c.name, SUM(o.total_amount) AS lifetime_value
FROM Customers c
JOIN Orders o ON o.customer_id = c.id
GROUP BY c.id, c.name;
Add OR REPLACE so the object ID remains; privileges and dependencies stay intact.
Create a view that exposes only allowed columns, grant SELECT on the view, and revoke direct table access to enforce security.
Don’t embed volatile functions like GETDATE() unless you expect re-evaluation each query. Avoid heavy aggregations in high-traffic views; materialize them instead.
Yes. Reference schema-qualified table names in the SELECT and create the view in any schema where you have CREATE privileges.
No. A standard view stores only SQL text. Each query runs the underlying SELECT, so results are always current.
Query SVV_INVALID_OBJECTS or SVV_VIEW_INFO. If the view shows as invalid, recreate it after fixing the underlying issue.