Consider a view named employee_summary created on a table employees. After executing the command DROP VIEW employee_summary;, what will be the result of querying SELECT * FROM employee_summary;?
DROP VIEW employee_summary; SELECT * FROM employee_summary;
Think about what happens to a view after it is dropped and whether it still exists for querying.
When a view is dropped, it is removed from the database. Any query referencing that view will raise an error because the view no longer exists.
You want to change the definition of an existing view named customer_orders to include only orders from the last year. Which of the following SQL commands correctly updates the view?
Think about how to redefine a view without dropping it first.
Standard SQL does not support ALTER VIEW to change the query. Instead, CREATE OR REPLACE VIEW is used to redefine the view.
If a view sales_summary is dropped, which of the following statements about objects depending on this view is true?
Consider how databases handle dependencies when dropping objects.
Most databases prevent dropping a view if other objects depend on it, unless those dependent objects are dropped first or the drop is done with CASCADE.
Given the command below, why does it fail in most SQL databases?
ALTER VIEW product_list AS SELECT id, name FROM products WHERE active = TRUE;
ALTER VIEW product_list AS SELECT id, name FROM products WHERE active = TRUE;
Think about the standard way to change a view's query.
ALTER VIEW is not supported for changing the query in many SQL dialects. Instead, CREATE OR REPLACE VIEW is used.
You need to update a large view monthly_report used by many users. Dropping and recreating the view causes errors for users querying it during the update. Which approach minimizes downtime and errors?
Consider atomic operations that do not remove the view before recreating it.
CREATE OR REPLACE VIEW updates the view atomically, so users querying the view do not experience errors or downtime.