Views are saved SQL statements, and known as “Virtual Table” also. View cannot store data (except Indexed Views). They only refer to data present in tables.
create view viewname
as
select columnname from tablename
but if the table schema will be changed (here schema means the fields those were fetch in views), then view will raise error on execute.
That’s why we create views with SCHEMABINDING keyword. It will not allow user to make change in schema.
Create view viewname
With schemabinding
As
Select columnname from ownername.tablename
Note: to use view with schemabinding option, we need to write tablename with ownername i.e. dbo.tab_employee, and select * statement is not permitted in this view.
Create view with encryption is the other concept, user will not be able to see the definition of the view after it is created, view definition will be stored in an encrypted format in the system table named SYSCOMMENTS. Once encrypted, there is no way to decrypt it back.
Create view viewname
With Enryption
As
Select columnname from tablename
To check the definition of the View, we need to write this query.
Select * from syscomments
where id=(select id from sysobjects where xtype=’V’ and name=’viewname’)
Views can be used to insert/update and delete data from a table. You can use instead of trigger only on Views.
Limitation of Views:
• Select into statements are not allowed
• Cant use temp table in views
• Cant pass parameters to views.
|
| Author: Nithya 02 May 2008 | Member Level: Bronze Points : 2 |
View
A view is a virtual table that consists of columns from one or more tables. Though it is similar to a table, it is stored in the database. It is a query stored as an object. Hence, a view is an object that derives its data from one or more tables. These tables are referred to as base or underlying tables.
Once you have defined a view, you can reference it like any other table in a database.
A view serves as a security mechanism. This ensures that users are able to retrieve and modify only the data seen by them. Users cannot see or access the remaining data in the underlying tables. A view also serves as a mechanism to simplify query execution. Complex queries can be stored in the form as a view, and data from the view can be extracted using simple queries.
Example
Consider the Publishers table below. If you want users to see only two columns in the table, you can create a view called vwPublishers that will refer to the Publishers table and the two columns required. You can grant Permissions to users to use the view and revoke Permissions from the base Publishers table. This way, users will be able to view only the two columns referred to by the view. They will not be able to query on the Publishers table.
Publishers
Publd
PubName
City
State
Country
0736
New Moon Books
Boston
MA
USA
0877
Binnet & Hardly
Washington
DC
USA
1389
Algodata Infosystems
Berkeley
CA
USA
1622
Five Lakes Publishing
Chicago
IL
USA
VW Publishers
Publd
PubName
0736
New Moon Books
0877
Binnet & Hardly
1389
Algodata Infosystems
1622
Five Lakes Publishing
Views ensure the security of data by restricting access to the following data:
Specific rows of the tables.
Specific columns of the tables.
Specific rows and columns of the tables.
Rows fetched by using joins.
Statistical summary of data in a given tables.
Subsets of another view or a subset of views and tables.
Some common examples of views are:
A subset of rows or columns of a base table.
A union of two or more tables.
A join of two or more tables.
A statistical summary of base tables.
A subset of another view, or some combination of views and base table.
Creating Views
A view can be created by using the CREATE VIEW statement.
Syntax
CREATE VIEW view_name
[(column_name[,column_name]….)]
[WITH ENCRYPTION]
AS select_statement [WITH CHECK OPTION]
Where:
view_name specifies the name of the view and must follow the rules for identifiers.
column_name specifies the name of the column to be used in view. If the column_name option is not specified, then the view is created with the same columns as specified in the select_statement.
WITH ENCRYPTION encrypts the text for the view in the syscomments table.
AS specifies the actions that will be performed by the view.
select_statement specifies the SELECT Statement that defines a view. The view may use the data contained in other views and tables.
WITH CHECK OPTION forces the data modification statements to fulfill the criteria given in the SELECT statement defining the view. It also ensures that the data is visible after the modifications are made permanent.
The restrictions imposed on views are as follows:
A view can be created only in the current database.
The name of a view must follow the rules for identifiers and must not be the same as that of the base table.
A view can be created only if there is a SELECT permission on its base table.
A SELECT INTO statement cannot be used in view declaration statement.
A trigger or an index cannot be defined on a view.
The CREATE VIEW statement cannot be combined with other SQL statements in a single batch.
Example
CREATE VIEW vwCustomer
AS
SELECT CustomerId, Company Name, Phone
FROM Customers
Creates a view called vwCustomer. Note that the view is a query stored as an object. The data is derived from the columns of the base table Customers.
You use the view by querying the view like a table.
SELECT *FROM vwCUSTOMER
The output of the SELECT statement is:
CustomerId
Company Name
Phone
ALFKI
Alfreds Futterkiste
030-0074321
ANTON
Antonio Moreno Taqueria
(5)555-3932
(91 rows affected)
|
| Author: thebarrett27 16 Jun 2008 | Member Level: Bronze Points : 0 |
thanks to both of you sharing nice information
|
| Author: Gaurav Agrawal 19 Jun 2008 | Member Level: Silver Points : 2 |
Hi kapil,
Good article but could have been better.
Your article is for person who has worked on views and it will be difficult for a person who have a no idea regarding view.
thanks to share your knowledge with us.
Keep Posting and help your fellow developers.
Regards
Gaurav Agrawal
|
| Author: Bunty 20 Jun 2008 | Member Level: Diamond Points : 1 |
Hi,
Nice attempt to explain the concept of view.
But try it to explain in more simpler way.
Keep posting.
Good try.
|
| Author: Chandra Sheker.G 21 Jun 2008 | Member Level: Gold Points : 2 |
A view is really nothing more than a virtual table. That is, it looks like a table and behaves like one, but it exists only in a compiled form. In effect, the table is insubstantiated when the view is referenced. You can refer to this virtual table (the view) in any query in which you could refer to a 'real' table. There are some restrictions on this, especially with regards to updating via the view.
A view cannot take parameters. But it can be used as a security mechanism without giving permission to the underlying tables. More importantly, you can use the view to BCP out a subset of data from the underlying table or tables.
A view is very handy for insulating the complexity of the database. A view can be constructed to hide the the technical details of the normalizations that may have been applied to the underlying data tables. Thus, the consumers can be presented with a view of the data which hides the complexities of the JOIN operations required of the underlying data tables, instead presenting a "flatter" view of the data that is easier to understand.
Processing queries
When a query containing a view is processed, the view definition is incorporated into the query plan, and this is how the virtual table is materialized. Therefore, you get the same performance results whether you explicitly code the view or merely referring to it. If you have a complex set of JOINs and you use that set often, it may be better to code them as a view, ensuring that all uses of the data perform the JOINs in the same way.
Queries are compiled into an execution plan, and then that plan is cached. If another query comes along that can use the same (cached) query plan, and nothing significant has changed since the plan was compiled, the plan will be re-used.
This simply avoids the cost of compiling the query plan. "Compiling" a plan doesn't make the query run faster - every query has to be "compiled" before it can run. It's just that circumstances may allow the compilation effort to be avoided on subsequent executions. Compilation can be a major process, because the optimizer that is responsible for creating the plan will try very hard to come up with the most efficient plan possible. Really complicated queries may convince the optimizer that it is worth it to spend more time trying to find the best plan, so compilation time goes up.
Faster execution of queries
It is true that using more stored procedures will likely result in a more efficient use of the cache and that may explain why, in general, a stored procedure execution seems to be faster than using a view returning the identical result set as shown below.
Assume the query " select * from emp " is written in a view. First create a view:
create view v_test1 as select * from test1
go
declare @start datetime
declare @end datetime
select @start = getdate()
select * from v_test1
select @end = getdate()
select datediff(ms,@start,@end) as 'Time taken in milliseconds'
(500 rows affected)
(1 row affected)
Time taken in milliseconds
--------------------------
410
(1 row affected)
Now:
create proc p_test1 as select * from test1
go
declare @start datetime
declare @end datetime
select @start = getdate()
exec p_test1
select @end = getdate()
select datediff(ms,@start,@end)
(500 rows affected)
(return status = 0)
Time taken in milliseconds
--------------------------
346
|