Views

Views in a nutshell

• virtual table
• based on 1 or more tables or views
• takes no storage space other than the definition of the view in the DD
• contains no data
• provides additional level of security
• hides implementation complexity
• lets you change the data you can access, applying operators, aggregation functions, filters etc. on the base table.
• isolates application from changes
• An updatable view allows you to insert, update, and delete rows by propagating the changes to the base table
• The data dictionary views ALL_UPDATABLE_COLUMNS indicate which view columns are updatable.
• Views which are not updatable can be modified using INSTEAD OF trigger.
• can be replaced with a CREATE OR REPLACE VIEW statement. The REPLACE option updates the current view definition but preserves the present security authorizations.
• lets you reorder columns easily with a CREATE OR REPLACE rather than going into a messy drop column for the base table with data
• The underlying SQL definition of the view can be read via select text from user_views for the view.
• Oracle does not enforce constraints on views. Instead, views are subject to the constraints of their base tables.

Difference b/w Views & materialized Views

Other than the word "view" in their names and the fact that both are defined by an underlying SQL, there is little else common between Oracle views and materialized views – yet they can be a source of great confusion to beginners. Here’s a summary of the key differences between views and materialized views, to put an end to all mix-ups. By the end of the article, you should be in a position to decide if your specific scenario needs a view, a materialized view, or neither.

1. Moment Of Execution: A view’s SQL is executed at run-time. The results are fetched from the view’s base tables when the view is queried.A materialized view (called snapshot in older Oracle versions) is a "pre-answered" query – the query is executed when the materialized view is refreshed.Its result is stored in the database and the query only browses the result.
2. Space: A view occupies no space (other than that for its definition in the data dictionary). A materialized view occupies space.It exists in the same way as a table: it sits on a disk and could be indexed or partitioned.
3. Freshness of Output: A view’s output is built on the fly; it shows real-time data from the base tables being queried. A materialized view does not reflect real-time data. The data is only as up to date as the last time the materialized view was refreshed.
4. Where To Use: A view is best used when: You want to hide the implementation details of a complex query. You want to restrict access to a set of rows/columns in the base tables.A materialized view is best used when: You have a really big table and people do frequent aggregates on it, and you want fast response You don’t mind the result being a little out of date, or your application data has more queries than updates (as in a BI/data warehousing system)

Caution! Are you creating a materialized view to avoid the pain of tuning a query? Don’t do it! A materialized view brings with it the overhead of maintaining extra DB objects that need regular refresh besides giving you out-of-date data, all for something that might have been fixed by writing better code. Whether your query runs directly on tables, on views or via materialized views, it must be the most efficient query possible. Materialized views are NOT a quick fix for bad code.

Inline Views

select * from (select ename, sal, dense_rank() over(order by sal desc) dr from emp) where dr = 4;