RonKyle (8/21/2013)

---

As a VB Programmer, I developed a lot of processes using disconnected recordsets. I used stored procedures to retrieve the initial sets. However, the additions and changes made by the recordset object required direct access to the tables. For that reason alone, I couldn't have used views. I've seen this technique recommended before, but personally have found very little use for views in an OLTP environment. I've used them to some extent in an OLAP environment to allow me to pull a subset or higher level from a dimension table (e.g. create a quarter hour view from a dimension table that has all the minutes, a month view from a date dimension that has days or a sub list of inspectors from technicians). In one of the Kimball books I read recently views were recommended for all the tables so that the auditing information that was of no use to the end users could be shielded. This is also intriguing, but you can't set the referetial integrity among the views in the same manner as tables.

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.

Having prefixed my objects for 15 years now, I find the advantages outweigh these small disadvatanges. Occasionally the types change, but that is really very uncommon and not a reason to completely disregard a naming convention system.