Question

how do views act as a mediator between the actual tables and an end user ? what’s the internal process which occurs when a view is created. i mean that when a view is created on a table, then does it stands like a wall between the table and the end user or else? how do views protect the actual tables, only with the check option? but if a user inserts directly into the table then how come do i protect the actual tables?

if he/she does not use : insert into **vw** values(), but uses: insert into **table_name** values() , then how is the table protected now?

Answer 1

Non-materialized views are just prepackaged SQL queries. They execute the same as any derived table/inline view. Multiple references to the same view will run the query the view contains for every reference. IE:

CREATE VIEW vw_example AS
  SELECT id, column, date_column FROM ITEMS

SELECT x.*, y.*
  FROM vw_example x
  JOIN vw_example y ON y.id = x.id

…translates into being:

SELECT x.*, y.*
  FROM (SELECT id, column, date_column FROM ITEMS) x
  JOIN (SELECT id, column, date_column FROM ITEMS) y ON y.id = x.id

Caching

The primary benefit is caching because the query will be identical. Queries are cached, including the execution plan, in order to make the query run faster later on because the execution plan has been generated already. Caching often requires queries to be identical to the point of case sensitivity, and expires eventually.

Predicate Pushing

Another potential benefit is that views often allow “predicate pushing”, where criteria specified on the view can be pushed into the query the view represents by the optimizer. This means that the query could scan the table once, rather than scan the table in order to present the resultset to the outer/ultimate query.

SELECT x.*
  FROM vw_example x
 WHERE x.column = 'y'

…could be interpreted by the optimizer as:

SELECT id, column, date_column 
  FROM ITEMS
 WHERE x.column = 'y'

The decision for predicate pushing lies solely with the optimizer. I’m unaware of any ability for a developer to force the decision, only that it really depends on the query the view uses and what additional criteria is being applied.

Commentary on Typical Use of Non-materialized Views

Sadly, it’s very common to see a non-materialized SQL view used for nothing more than encapsulation to simplify writing queries — simplification which isn’t a recommended practice either. SQL is SET based, and doesn’t optimize well using procedural approaches. Layering views on top of one another is also not a recommended practice.

Updateable Views

Non-materialized views are also updatable, but there are restrictions because a view can be made of numerous tables joined together. An updatable, non-materialized view will stop a user from being able to insert new records, but could update existing ones. The CHECK OPTION depends on the query used to create the view for enforcing a degree of update restriction, but it’s not enough to ensure none will ever happen. This demonstrates that the only reliable means of securing against unwanted add/editing/deletion is to grant proper privileges to the user, preferably via a role.