CREATE VIEW stores a SELECT statement under a view name so that users can query the view as if it were a table. The view does not hold data itself; it dynamically returns rows produced by the underlying query each time it is referenced. Views encapsulate complex joins or calculations, enforce security by exposing only specific columns, and provide a stable interface to evolving schemas. Some dialects allow updatable views, with restrictions, and support modifiers like OR REPLACE, IF NOT EXISTS, WITH CHECK OPTION, or SECURITY BARER. Because a view depends on base tables, altering or dropping those tables can invalidate the view. Performance depends on the optimizer; most engines rewrite a view reference into the underlying query while others can cache results or support materialized views for persistence.
view_name
(identifier) - Name of the view to create.column_list
(optional list) - Overrides column names returned by the query.select_statement
(query) - Any valid SELECT statement.OR REPLACE
(keyword) - Replaces an existing view of the same name.WITH CHECK OPTION
(keyword) - Prevents inserts or updates through the view that violate its predicate.IF NOT EXISTS – keyword
(varies) - Skip creation if the view already exists.ALTER VIEW, DROP VIEW, MATERIALIZED VIEW, SELECT, WITH CHECK OPTION, OR REPLACE
SQL-92 standard
A table physically stores data on disk. A view stores only the SELECT definition and returns data dynamically from underlying tables.
Standard views cannot be indexed directly. Some databases allow indexed or materialized views which persist and index their data.
Run `DROP VIEW view_name;` Use `IF EXISTS` in dialects that support it to avoid errors if the view is missing.
Performance is usually similar because the optimizer expands the view into the underlying query. For heavy aggregations or joins, consider materialized views or additional indexing.