From an application point of view it doesn't matter whether the underlying object is a table or view.

From a DBA point of view I want the freedom to refactor without having to kick off a big programme of work. I worked on a small refactoring project to move tables from a line-of-business specific database into a central shared database. Due to the sprawling nature of the legacy app the most cost effective way of doing this was to move the table to the shared DB but put a view in place of the original table.

This mean we had an object called tbl_<tablename> that was actually a view.

We also found that for performance purposes one of the views needed to be turned into a physical table. This meant we now had a table called vw_<viewname> that was actually a table!

That is a real concrete example of why I don't like prefixes(or suffixes) to denote object type.

I do use views for security purposes. There are a number of downsides and challenges

• Restrictions around indexing
• Problems documenting views in our chosen auto-documentation tool. Specifically the tool required special tags in the header rather than sp_addextended property. Also columns did not have their extended properties resolved back to the source table.

Foreign key obscurity makes reverse engineering DB diagrams in Visio a pain.