Downsides to "WITH SCHEMABINDING" in SQL Server?

Solution 1:

You wont be able to alter/drop the table, unless you drop the view first.

Solution 2:

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.