Views can be thought of as a virtual table or stored query.

The results of view are not stored in database (except for indexed views). The data accessed through a view is actually constructed using standard T-SQL select command and can come from one to many different base tables or even other views. This T-SQL select command is stored as a database object (a vi ew). Developers can use the results from the view by referencing the view name in T-SQL statements the same way they would reference a real table. There are several advantages of using a view. They are: 1) A view can be used to limit the user to see only few columns in a table. A view can join several tables, in several databases on several servers, but all the user use is the view's name. 2) We can use views to manipulate the data. 3) Bcp utility and bulk insert works with a view. Basic syntax for a view goes like this: Create View <View Name> As <Select statement> GO Eg : Create View myView As Select EmpId , EmpName from Employees GO Here it will create a view named myView. Now instead of using the complete selec t statement to return the above result, you can just use a simple statement like this Select * from myView One of the important options that are used while creating a view is SCHEMABINDIN G. SCHEMABINDING Option Imagine that you have created a view with out SCHEMABINDING option and you have altered the schema of underlying table (deleted one column). Next time when you run your view, it will fail. Here is when SCHEMABINDING comes into picture. Creating a view wit h SCHEMABINDING option locks the underlying tables and prevents any changes that m ay change the table schema. Here is an example of a view with schemabinding option: Create View myView With schemabinding As Select EmpId , EmpName from dbo.Employees GO Remember that the object should be referred by their two-part name ( ownername.o bjectname) eg: dbo.Employees

Now you wont be able to execute the alter statement on Employees table n SQL Server, views are not bound to the schema of the base tables by default. In such case we may change the schema of the base table at any time, regardless of the fact that the associated view may or may not work with the new schema. We can even dr op the underlying table while keeping the associated view without any warning. In this case when the view is used, we will get an invalid object name error for the base table. So if you want to create an index on a view or you want to preserve the base tab le schema once a view has been defined, in both these cases you have to use the "WITH SCHE MABINDING" clause to bind the view to the schema of the base tables. To use schema binding for views, first we will create a sample table in Adventur eWorks database then a view "vw_sampleView" is created on this new table. Create sample table and sample view USE AdventureWorks GO SELECT * INTO SampleTable FROM sales.SalesOrderDetail GO CREATE VIEW [dbo].[vw_sampleView] WITH SCHEMABINDING AS SELECT salesorderid, productid, unitprice, linetotal, rowguid,modifieddate FROM dbo.SAMPLETABLE GO --If the view already existed we could use this to add SCHEMABINDING ALTER VIEW [dbo].[vw_sampleView] WITH SCHEMABINDING AS SELECT salesorderid, productid, unitprice, linetotal, rowguid,modifieddate FROM dbo.SAMPLETABLE GO Be aware that if you do not use the schema name, (dbo) in this case, then you wi ll get the following error while creating the view. "Cannot schema bind view 'dbo.vw_sample View' because name 'SAMPLETABLE' is invalid for schema binding. Names must be in two-p art format and an object cannot reference itself." This error is only generated in case of schema bound views. In the case of ordin ary views you will not get this error. So here we are with a SCHEMABOUND view "sampleView" on base table "sampleTable". Now we will check that we are able to create an index on the view.

First, while "but objects that are referenced by schema bound objects cannot hav e their definition changed." is technically true, you cannot generally rely on schemabin

ding as a way to prevent changes by people with appropriate permissions. SSMS wi ll give you a warning, but then remove schemabinding in order to make changes or dered through the gui. Also, it is worth noting that schemabinding is required for a view if the view i s going to be indexed. SCHEMABINDING is an option that can be applied to Views or Functions. When used , it forces SQL Server to create dependencies between any objects referenced within the View or Function, to the View or Function itself. What this means is that the referenced objects cannot have their definitions altered whilst the schema-bound View or Function exists, which ensures the integrity of the View or Function. Ok, so it means you have to alter the View or Function to remove the schema bind ing if you want to change one of the referenced objects. But is this really such a big ove rhead? I see this as a good thing, as it forces you to think about the impacts of the changes you are making. You are also forced to qualify all of your table s in a View, and all objects in a Function (i.e. schema.object). Though I'm sur e everyone already does this as good practice, right? Onto the benefits, and why we should go through the pains of dealing with schema -bound objects....

Integrity - as mentioned above, if an object is schema-bound then the objects it references cannot have their definitions changed whilst the schema binding exis ts. This ensures the integrity of the View or Function stopping poorly impacted changes being made. Note that SQL Server is intelligent enough to recognise ce rtain changes that do not affect the schema-bound View or Function, e.g. if a nu mber of columns from a table are referenced within a schema-bound Function, then dropping a column not referenced in the Function would still be allowed. Performance - UDFs can often be the cause of poorly performing queries, due to t he query optimizer's inability to look into the function to determine the best p lan. If the function is a simple scalar function and does not reference any ta bles, without schema binding the optimizer must assume data is being accessed an d will add a spool operator to protect itself from underlying data changes. Add ing the SCHEMABINDING option stops this occurring as the optimizer knows there i s no data access and will avoid the use of unnecessary spools. An article here goes into more detail on the subject.

Unfortunately the performance improvements do not extend beyond the example abov e, however the integrity benefits should be enough to warrant the use of the opt ion. Microsoft clearly agree with this statement as they force the use of SCHEM ABINDING for any Views on which an index is to be created. I'm a little baffled as to why the creation of an indexed view does not just create the schema bindi ng automatically, and I'd love someone to post a comment with the answer to that question! So there you have it; a simple way of improving scalar UDF performance, and also ensuring a greater degree of database integrity.