[thelist] ASP: More Selective Select

Jason Handby jasonh at pavilion.co.uk
Thu Jul 3 09:03:44 CDT 2003


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



More information about the thelist mailing list