I’ve never run into the situation where I was worried about a table being accidentally dropped (maybe I should have been?) as I usually let a good security model restrict that.  But, accidents do happen.

So, if I ever need to make sure a table isn’t dropped I can use this technique by Roman Rehak.  He creates a view using the SCHEMABINDING option, which binds the view to the table/schema so that the table (or other object) can’t be dropped without the view being dropped or modified.  Taking a peek at BOL it looks like the same technique can also be used to make sure a table structure is not manipulated, as an ALTER statement will fail on a table that is dependent on a view, if that ALTER statement will affect the view definition.

In a dev environment with multiple developers possibly affecting a DB structure, I can see the ALTER check being more beneficial than the delete.  But, if you get both for the same price…beautiful!