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

Oh, there are DEFINITELY DOWNSIDES to using SCHEMABINDING - these come from fact the SCHEMABINDING, especially when coupled with COMPUTED columns "LOCKS" THE RELATIONSHIPS and makes some "trivial changes" darn near impossible.

1. Create a table.
2. Create a SCHEMABOUND UDF.
3. Create a COMPUTED PERSISTED column that references the UDF.
4. Add an INDEX over said column.
5. Try to update the UDF.

Good luck with that one!

1. The UDF can't be dropped or altered because it is SCHEMABOUND.
2. The COLUMN can't be dropped because it is used in an INDEX.
3. The COLUMN can't be altered because it is COMPUTED.

Well, frak. Really..!?! My day just became a PITA. (Now, tools like ApexSQL Diff can handle this when provided with a modified schema, but the issue is here that I can't even modify the schema to begin with!)

I'm not against SCHEMABINDING, mind (and it's needed for a UDF in this case), but I'm against there not being a way (that I can find) to "temporarily disable" the SCHEMABINDING.