SQL Server: Non-Clustered composite index

SQL developer has created a table of contacts using following statement:

CREATE TABLE Contact (ContactID int PRIMARY KEY, ContactType nvarchar(10), FirstName nvarchar(30) NOT NULL, LastName nvarchar(50) NOT NULL, Territory nvarchar(20), Region nvarchar(10), RepID int, InitContact datetime
DEFAULT GETDATE());

SQL developer wants to optimize the stored procedure frequently run on the table. To optimize the query in the stored procedure, DBA/Developer should create a composite index on the two columns. As contains many contacts, and each territory contains only a few. Because there are fewer Region values than Territory values, DBA/Developer should specify the Territory column first when creating the index. With the composite index, SQL Server will find the rows that match the territory and region criteria in the WHERE clause with a single index search. The search will be performed only by reading the index pages, and the data pages will be accessed only once to retrieve the result set. DBA/Developer might create the index using the following statement:

CREATE INDEX IX_Contact_TerritoryRegion

ON Contact (Territory, Region);

Using this index would generally offer better performance than if DBA/Developer had created the index with the Region column first, because the Territorycolumn contains more unique values. DBA/Developer should not create a view on the Contact table and modify the stored procedure to use the view. Using a view would not improve performance. The stored procedure would still have to query the view, and the view would access the underlying table. DBA/Developer should not create two non clustered indexes, one on the Territory column and one on the Region column. In this scenario, a single composite non clustered index would provide better performance. Although SQL Server can use more than one index on a table, it is unlikely that the index on the Region column would be used in this scenario because of the low uniqueness of the column's values. DBA/Developer should not re-create the stored procedure including the WITH SCHEMABINDING clause because the WITH SCHEMABINDING clause is not allowed for a stored procedure. In addition, it has no affect on performance. DBA/Developer can include the WITH SCHEMABINDING clause in a CREATE VIEW statement to ensure that no base tables on which the view is based are dropped or modified in a way that might affect the view's definition. To drop base tables or make such modifications, a user would first need to drop the view, alter the view omitting SCHEMABINDING, or alter the view to remove any unwanted dependencies. DBA/Developer can also include the WITH SCHEMABINDING clause when creating a function to ensure base tables are not changed in such a way that would render the function unusable.