[AccessD] Table naming conventions

I do use naming conventions in VB.Net, at least as much as I'm allowed
to.  My boss decreed we would use suffixes instead of prefixes to name
forms, reports, etc., so related objects would sort together in the
project.  Now you have to read the entire name of the object to find out
what it is!  We've never used prefixes on table names, or fields, so
that hasn't been an issue in converting to .Net.  I prefer prefixes on
table names and I prefer prefixes because they allow my eye to skate
over the object types I don't want to examine without having to read the
entire name of the object.  SIGH!  I can't have everything I want. 

Charlotte


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: Thursday, March 02, 2006 11:53 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Table naming conventions


<<<
The underscore annoys me because it is harder to type than just a
> capital letter,
>>>
I don't use underscore because they weren't used in LRNC.
But typing it for me isn't a big trouble :)

<<<
 I really think it boils down to whatever works for the developer,
>>>
Sure it is. I just accepted LRNC and I use it naturally for a long time.
But to use other naming conventions if they are well systematically
designed 
and applied (like JC's :)) wouldn't be a problem for me:)

For example in VB.NET/C# I do not use Hungarian notation/LRNC as it's 
recommended by MS and I like it too - I'm flexible :)

<<<
It only becomes an issue in a team development environment, where
> using the same or at least compatible naming conventions is critical.
>>>
Yes, in a team environment the systematic use of naming conventions is 
critical - the naming conventions approved by team leader :) - I mean
any 
discussions what is better to use prefixes or suffixes or both or ...
should 
be "rudely"/decisively suppressed by team leader as soon as naming 
conventions are defined  and accepted and a project starts - teamwork
isn't 
a discussion club... :)

Prefixes or suffixes in variables and even tables', queries' etc. names
are 
getting obsolete - this is my current opinion. I still use them in MS 
Access/VBA but not in VS.NET development (except control names prefixes
but 
these are also becoming not easy to use with so many different types of 
controls in VS.NET 2005 Winforms).

Still using table name prefixes in tables' field names look reasonable
from 
practical point of view (to build queries quicker without field names 
collisions first of all) but with mainstream tendency of relational 
back-ends becoming something more than just normalized databases and 
morphing to XML hierarchies ... -> and finally somewhere in the future
to 
ORDBMSs or pure OODBMSs - with this clear mainstream tendency the usage
of 
prefixes or suffixes is clearly becoming generally depreciated...

I do use tbl, tlkp, qsel, qapp, ... etc. prefixes with table names and 
queries but this usage is looking more and more obsolete because a table
can 
migrate to a set of queries(views), stored procedures, UDFs, web
services 
etc. and vice versa then renaming could become a real time consuming and

error prone problem...

I did use LRNC prefixes to clearly recognize source object type, to
group 
objects, to speed-up development but it's clear that in real life modern

development using only prefixes or only suffixes or both isn't enough - 
there could be many useful groupings/sortings of the same types or
different 
types of objects - and modern development tools supply different
features to 
natively keep and use such groupings/sortings....

There should be clear practical reasons to use prefixes or suffixes as
it 
was with LRNC and MS Access/Office development for the last 10 years or
with 
Hungarian notation and MSVC++ for the last 15 years ago, VB6 for the
last 10 
years...

I mean it shouldn't be like "We use prefixes or suffixes because our
fathers 
and grand-fathers used them, we forgot/don't know why they are so keen
and 
what for they are needed, we do not see any practical reasons now to use

them but we do use them to keep the traditions alive...."

Shamil