Naming Conventions - Should I use them?

[Guest]

I am starting a db and I have recently heard that naming conventions are no
longer recommended. This goes against any traditional understanding I was
aware of. Does anyone have any thoughts on the subject?

Regards,

JM

 

[Douglas J. Steele]

The "no naming conventions" school of thought seems to be associated with
..Net, not Access. I believe the rationale is that there are so many more
objects in .Net that it's virtually impossible to come up with meaningful
acroynyms to use as prefixes. As well, the intellisense is much better, so
you can get easily get information about a variable (other than the scope, I
believe) without needing a prefix.

That having been said, I still use a naming convention in .Net: old habit
die hard! <g>

 

[Duane Hookom]

I wouldn't do any Access programming (and other environments) without naming
conventions. Jeff Conrad has some links at
http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html#NamingConventions
and Tony Toews http://www.granite.ab.ca/access/tablefieldnaming.htm

 

[Rick Brandt]

I am starting a db and I have recently heard that naming conventions
are no longer recommended. This goes against any traditional
understanding I was aware of. Does anyone have any thoughts on the
subject?

Regards,

JM

Use them if you want. Personally, I've never used them and see little benefit
to them. Object oriented languages tend to discourage them. They are mostly
used in VB and Access from what I've seen.

 

[Tim Ferguson]

Use them if you want. Personally, I've never used them and see little
benefit to them. Object oriented languages tend to discourage them.
They are mostly used in VB and Access from what I've seen.

The first sensible I thing I read on this subject for a long time was
here:

<http://www.joelonsoftware.com/articles/Wrong.html>

Take the time to follow up on the links, particularly on the real history
of the hungarian notation (and then just ponder on how different life
could have been if we had just been using it right...)

It's one of the web pages that has had the biggest single impact on
(well, at least certain aspects of) my life.

B Wishes


Tim F

 

[Guest]

... on the real history
of the hungarian notation (and then just ponder on how different life
could have been if we had just been using it right...)

There is this misconception that a naming convention implies Hungarian
notation (which I consider to be evil but sometimes have to use under
protest). But naming conventions span a much broader universe, and are an
absolute necessity in organizing multi-person projects. For example, is there
any significance to tables names that are singular vs. plural? Should a name
of an db object apperaing in a query indicate whether the object is a table
or a view? Should the name indicate whether the object can be created &
destroyed at will, or whether its existence depends on other entities? Will
the name be revealed to the end user and hence should be meaningful in the
natural language, or only to the developer or database admin? If your app
breaks (and they all do sooner or later), and someone else studies your data
model, or if you come back to it many months later, how easy will it be to
decipher what you really intended to do? From long-time personal experience,
my recommendation is: establish a naming convention, stick to it, and
DOCUMENT IT!
-Ted

 

[peregenem]

I am starting a db and I have recently heard that naming conventions are no
longer recommended. This goes against any traditional understanding I was
aware of. Does anyone have any thoughts on the subject?

Because this is the 'tablesdbdesign' group, I'm assuming the OP is
referring to the naming of metadata elements (tables, columns, etc).
There is an ISO standard for this (ISO 11179-5):

http://metadata-standards.org/11179/#11179-5

 

[Vincent Johns]

Because this is the 'tablesdbdesign' group, I'm assuming the OP is
referring to the naming of metadata elements (tables, columns, etc).
There is an ISO standard for this (ISO 11179-5):

http://metadata-standards.org/11179/#11179-5

The ISO document gives some good suggestions. In case it seems a bit
abstract, you might consider jumping to Annex A, which contains some
specific suggestions for naming conventions.

One convention that I have found helpful in Access is to give each table
a primary key with a unique name, formed by appending "ID" to the name
of the table. For example, the key for "Pets" would be "PetsID". I use
that same name as a foreign key in other tables linking to the first
one, and Access picks up on this, automatically linking them in Query
Design View.

I don't depend completely on names to convey semantic information about
fields, tables, queries, etc. For example, I usually put a fair amount
of stuff into the Comment field in Table Design View (for fields) or
Macro Design View (for actions), and into the Description property of
each Table, Query, Form, etc. (description of the overall object). This
helps me keep track of where everything is, very useful 6 months later.
Last month, I wrote a database with a couple of dozen tables and about
150 queries -- without consistent names and suitable comments, there was
no way I could have kept track of them all. And now that a few weeks
have passed since I looked at it, I don't remember the details but am
confident that I could quickly find the correct objects to modify if
changes are ever needed.

In summary, I would strongly recommend adopting conventions that make
sense to you (and anyone else who has to use your named entities) -- it
could save lots of headaches.

-- Vincent Johns <[email protected]>
Please feel free to quote anything I say here.