Achieving Abstraction using SQL Views

The power behind views lies in something called abstraction.
Abstraction frees your program from considering how information is retrieved from the table. In this case, since you are referring to the view to get information from the table, and you are not querying the table directly.
For example, suppose your manager walks in and has changed his mind. He wants to see the results for the state of California instead of Utah.
Now you have to go update all your queries used in reports so you can see the correct state, right?

This is not correct.
All you need to do is to update the view. Because all the queries reference the view for their information, you can make one change, update the state, and all your queries using that view are automatically updated as well.
Consider views whenever you perform a query repeatedly against the database with only slightly different parameters.

There are three good reasons to include views in the design of a database:

1. As mentioned earlier, views provide a significant security mechanism by restricting users from viewing portions of a schema to which they should not have access.
2. Views can simplify the design of a database for technologically unsophisticated users.
3. Because views are stored as named queries, they can be used to store frequently used, complex queries. The queries can then be executed by using the name of the view in a simple query.

Like other structural elements in a relational database, views can be created and destroyed at any time. However, because views do not contain stored data but only specification of a query that will generate a virtual table, adding or removing view definitions has no impact on base tables or the data they contain. Removing a view will create problems only when that view is used in an application program and the program is not modified to work with a 1) different view or 2) base table.