Hello, another thread compelled me to spell out what my supposed state-of-the-art thinking is on database object names.
Sql Server has no concept of a namespace for object names. That is, all names for tables and views (and more) must be unique. Well, there is in fact a single namespacing concept - the owner!
We create owners for the logical namespaces in our product. The views and (primarily) computed tables that belong to that namespace will be owned by the appropriate sql account. In that way, intra-namespace calls between relations need not be qualified, but inter-namespace calls must be.
Also, the same relation name can be used by various subsystems, as they implement their views. This avoids the ugly problem of assigning arbitrary suffixes to view names. For example, consider possible view names over some table "dbo.Equipment" - "dbo.EquipmentSummary", "dbo.EquipmentView", "dbo.EquipmentDetails". OUCH. I prefer “[MyProduct.Admin].Equipment“, “[MyProduct.Search].Equipment“.
The application does not login to sql using these accounts - yet. In time, we might do this and finally be able to take advantage of sql server's security mechanisms.
It makes sense in a twisted way, hey? The namespaces "own" the relations! Of course, triggers and procedures are also treated in this way. It's helpful when a certain base table has many orthogonal triggers that those triggers are owned by the subsystem that requires them.
Note that, within Enterprise Manager, you will sort by Owner, not Name, to get a nice subsystem-centric view of your db objects.
We are early into the implementation of this approach. Please give me your feedback/concerns, thanks!