Downsides to “WITH SCHEMABINDING” in SQL Server?

Question

I have a database with hundreds of awkwardly named tables in it (CG001T, GH066L, etc), and I have views on every one with its \"friendly\" name (the view \"CUSTOMERS\" is \"SELE

Answer 1

Another downside is that you need to use schema qualified names for everything: You'll get a load of error messages like this:

Cannot schema bind view 'view' because name 'table' is invalid for schema binding. Names must be in two-part format and an object cannot reference itself.

Also to 'switch off' schemabinding you do alter view which requires you to redefine the view's select statement. I think the only thing you dont have to redefine is any grants. This puts me off a lot as overwriting the view seems like an inherently unsafe operation.

Its a bit like the way adding not null constraints forces you to overwrite the column's data type - nasty!

You'll also have to redefine any other views or procedures that depend on the schema bound object you want to change... this means you may have to redefine (and possibly break) a large cascade of functions and views just to add (eg) a not null constraint to one column.

Personally I think this doesnt really represent a solution and its better to have a decent process whereby any database changes are applied automatically so it isnt a nightmare to change the database. That way you can have all your views + functions dropped and recreated from scratch (they get checked on creation anyway) as part of the process when you apply changes to tables.