Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

About Schema Binding
Schema binding essentially takes the things that your view is dependent upon (tables or other views),
and “binds” them to that view. The significance of this is that no one can make alterations to those
objects (CREATE, ALTER) unless they drop the schema-bound view first.
Why would you want to do this? Well, there are a few reasons why this can come in handy:
❑ It prevents your view from becoming “orphaned” by alterations in underlying objects. Imagine,
for a moment, that someone performs a DROP or makes some other change (even deleting a column
could cause your view grief), but doesn’t pay attention to your view. Oops. If the view is
schema bound, then this is prevented from happening.
❑ To allow indexed views: If you want an index on your view, you must create it using the
SCHEMABINDING option. (We’ll look at indexed views just a few paragraphs from now.)
❑ If you are going to create a schema-bound user-defined function (and there are instances where
your function must be schema bound) that references your view, then your view must also be
schema bound.
Keep these in mind as you are building your views.
Making Your View Look Lik e a Table with
VIEW_METADATA
This option has the effect of making your view look very much like an actual table to DB-LIB, ODBC,
and OLE-DB clients. Without this option, the metadata passed back to the client API is that of the base
table(s) that your view relies on.
Providing this metadata information is required to allow for any client-side cursors (cursors your client
application manages) to be updatable. Note that, if you want to support such cursors, you’re also going
to need to use an INSTEAD OF trigger.
Indexed (Materialized) V iews
Chapter 10: Views
When a view is referred to, the logic in the query that makes up the view is essentially incorporated into
the calling query. Unfortunately, this means that the calling query just gets that much more complex. The
extra overhead of figuring out the impact of the view (and what data it represents) on the fly can actually
get very high. What’s more, you’re often including additional joins into your query in the form of
the tables that are joined in the view. Indexed views give us a way of taking care of some of this impact
before the query is ever run.
An indexed view is essentially a view that has had a set of unique values “materialized” into the form of
a clustered index. The advantage of this is that it provides a very quick lookup in terms of pulling the
information behind a view together. After the first index (which must be a clustered index against a
unique set of values), SQL Server can also build additional indexes on the view using the cluster key
319