Rudy:
> > casey, a more important rule than using plural names for tables is
> > NOT to embed the "type of the thing" into the name of the thing
> >
> > for example, do not say tblEmployees or colFirstname
Pete:
> Rudy, you're the db guru, but you just blew away 10 years of best practice
> for me! I have proudly used naming conventions that prepend the
> object type
> ("tblEmployees", "qryEmployees", etc.). It's used in almost all
> the books I
> have read, especially those covering Access/VB and I have continued to use
> it as I moved on to SQL Server. I find it helpful to know the object type
> when looking at the code, sort of like when you prepend the data type to a
> variable, as in "intYears" or "strSQL" or "rstMyRecordset." This kind of
> thinking is so ingrained in my head I could never get rid of it.
> Why do you
> say not to do that? (I assume you are only talking about database objects
> and not variable names?)
I must admit that I've never seen the point of this either. (At least not
for tables. I do tend to prepend my view names with "v", mainly so I can
distinguish them from tables when I'm creating linked tables via ODBC in
Access.)
I guess the reason is that it's obvious from the statements it occurs in
that an object is a table (or view) without having to give it a suffix to
make it clear:
SELECT * FROM MyThing
implies that MyThing is a table (or view).
Putting the type in the name is arguably more useful in conventional
languages, where a variable's type isn't clear just from the syntax. For
example (in C#):
MyOtherThing = MyThing; // the type of MyThing isn't obvious
Jason