View:
Well,
a view simply isn't identical to a table, client or not,
and if you try to insert something into a view the error that will pop up will clearly
explain the difference.
so better mark them with a prefix so you can't mix it up ;o)

Reference Table:
I would call a table a reference table if it is i.e. a table which contains a n-m relation.
it just consists of foreign key references and maybe also some content fields,
but the main content is the n to m relation.
In my opinion the number of columns is irrelevant, but the relation by which the data
contained in the table is linked gives the context...

___

Markus Engelhardt
Web and Database Development
MCP

I prefix all of my views with 'vw' and make the same requirement of the developers where I work. The main reason you would want to add a prefix is to avoid problems where developers try to give objects the same name. For example, if you have a table named 'promo_ref', you can't have a view named 'promo_ref' (unless you give it a different owner).

I'd hardly call adding 'v' or 'vw' to the name of views "muddling your data model". That's like saying that a penny is muddling Bill Gates' bank account.

What I don't do is use underscores in object names. It's not a rule, just a preference. Underscores slow me down when I'm typing.

Naming standards are very good things. Common abbreviations are very good things.

Very good things can, however, be taken to silly extremes. We've got a logical modeling team tasked with, along with maintaining an enterprise logical model, establishing naming conventions. Unfortunately, these people work in the ethereal world of logical modeling, exclusively. They don't have to write code against the models they create, so naming every single table in a database Policy...* is not a problem for them even when we're talking about a couple of hundred tables, all inside a database named Policy. Establishing incomprehensible abbreviations like 'ddltbl' for deductible (do abbreviations generally add letters? note the new 'l') doesn't seem to slow down their work at all. The rest of us, dba's and developers, have been driven insane trying to get them to use an abbreviation like 'org' for organization instead of 'orgntzn'. I have, on more than one occasion, brought a dictionary over to their desk and pointed at common abbreviations defined with along with a word to no avail.

Don't get me wrong. I am in favor of practing a common approach. Just make sure the common approach makes sense.

Oh, and underscores in object names suck.

I agree with some of the ideas in the article, but I hate underscores in table field names.  Capitalizing each word within the name is just as readable and much easier to type (i.e., GrossAmountPaid).

And what's wrong with using a prefix and naming a table tblInvoices?

I try to avoid abbreviations unless their meaning is just as clear as the long version would have been.