Proper way to name objects..

[Mell via AccessMonster.com]

I have been told that if you don't name your tables, queries, forms & reports
like below than you did not build the db properly? Do these abbreviations
have to be put in front of the name to be policitally correct as a good
developer?


1. TABLES: tbl
2. QUERIES: qdf
3. FORMS: frm
4. REPORTS: rpt

Any suggestions would be greatly appreicated.

 

[Duane Hookom]

These are standards that have been around for a while. Most of us with some
experience use some form of these. For instance, I might name my queries:
qsel - Select Queries
qapp - Append
qdel - Delete
qtot - Totals
qxtb - Crosstab
qupd - Update
I think the key is to find a naming convention that means something to you
and try to be consistent. One thing you won't see in my object names is
spaces and punctuation.

Jeff Conrad has some links at
http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html#NamingConventions

One convention that I have found very useful is naming all of my fields
beginning with 3 characters that describe the table. For instance:
tblEmployees
=============
empEmpID autonumber primary key (Always)
empFirstName
empLastName
emp....

tblEmpTimeSheet
================
etsETSID autonumber primary key
etsEmpID link to tblEmployees.empEmpID
etsWorkDate
etsPrjID link to tblProjects.prjPrjID
etsWkTID link to tblWorkTypes.wktWkTID
ets...

 

[Lynn Trapp]

Mell,
Whoever told you that you MUST use those abbreviations to be developing your
databases properly didn't know what they were talking about. Those are
merely conventions that people have come up with and you can use them or
not. Personally, I do not use them. Instead, I have my own method for naming
things that serves to group like objects together. You can use the
conventional stuff or come up with your own.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Access Junkie List:
http://home.bendbroadband.com/conradsystems/accessjunkie.html

 

[Mell via AccessMonster.com]

Lynn,

Thank you so much.
I have done some db's the so called correct way and done some db's with out
the abbreviations.

Mell,
Whoever told you that you MUST use those abbreviations to be developing your
databases properly didn't know what they were talking about. Those are
merely conventions that people have come up with and you can use them or
not. Personally, I do not use them. Instead, I have my own method for naming
things that serves to group like objects together. You can use the
conventional stuff or come up with your own.

I have been told that if you don't name your tables, queries, forms &
reports

[quoted text clipped - 8 lines]

Any suggestions would be greatly appreicated.

 

[Tom Ellison]

Dear Lynn:

Exactly true!

What is important is to use some convention, and use it consistently.

You are programming in a object oriented environment. If you do not
classify object you create, you will likely duplicate names, with unhappy
and mysterious consequences. Having some convention is very important.
Which convention is unimportant, as long as it is consistent and distinct.

My convention is usually to affix the abbreviation at the END of the object
name, not the beginning. When I'm looking in an alphabetical list, this
seems very much handier.

If I have a table, a select query, and an append query to something I call
George, I see this alphabetical List:

GeorgeTbl
GeorgeQSel
GeorgeQApp

This is much more useful for my preferences.

Tom Ellison

 

[Jeff Boyce]

Mell

The prefixes are conventions, to make it easier to identify Access objects
at a glance. The key isn't THESE prefixes, it is adopting SOME convention,
then sticking to it. If you're the only one who will ever need to work on
your dbs, come up with something that works for you.

If there's a chance folks other than you will need to work "behind the
curtain" on your dbs, adopting a standard convention like this one would
help them out.

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Mell via AccessMonster.com]

Tom,

This is great!
Alphabetical List:
ABSOLUTELY.........

Dear Lynn:

Exactly true!

What is important is to use some convention, and use it consistently.

You are programming in a object oriented environment. If you do not
classify object you create, you will likely duplicate names, with unhappy
and mysterious consequences. Having some convention is very important.
Which convention is unimportant, as long as it is consistent and distinct.

My convention is usually to affix the abbreviation at the END of the object
name, not the beginning. When I'm looking in an alphabetical list, this
seems very much handier.

If I have a table, a select query, and an append query to something I call
George, I see this alphabetical List:

GeorgeTbl
GeorgeQSel
GeorgeQApp

This is much more useful for my preferences.

Tom Ellison

Mell,
Whoever told you that you MUST use those abbreviations to be developing

[quoted text clipped - 16 lines]

 

[Tom Ellison]

Dear Mell:

Well!

I'm glad if you liked it.

I know I certainly prefer suffixes to prefixes. They perform the same
essential purpose, but are handier in the alphabetical order.

Tom Ellison

Tom,

This is great!
Alphabetical List:
ABSOLUTELY.........

Dear Lynn:

Exactly true!

What is important is to use some convention, and use it consistently.

You are programming in a object oriented environment. If you do not
classify object you create, you will likely duplicate names, with unhappy
and mysterious consequences. Having some convention is very important.
Which convention is unimportant, as long as it is consistent and distinct.

My convention is usually to affix the abbreviation at the END of the
object
name, not the beginning. When I'm looking in an alphabetical list, this
seems very much handier.

If I have a table, a select query, and an append query to something I call
George, I see this alphabetical List:

GeorgeTbl
GeorgeQSel
GeorgeQApp

This is much more useful for my preferences.

Tom Ellison

Mell,
Whoever told you that you MUST use those abbreviations to be developing

[quoted text clipped - 16 lines]

Any suggestions would be greatly appreicated.

 

[Ken Sheridan]

While 'tags' are fine for objects like forms, reports modules etc I'm very
much against their use for table and column names. The convention for these
used by most SQL programmers of my acquaintance is to use plural or
collective nouns for tables, using terms which as closely as possible
represent the entity type which the table is modelling, e.g. Employees,
Orders etc. For column names singular nouns are generally used, again using
terms which as closely as possible describe the attribute which the column
represents, e.g. firstname, lastname orderdate. As you see the convention
here is to use lower case for column names, though personally I don't see any
real advantage in that and I tend to use CamelCase (not camelCase, note).

By keeping as close as possible to real English words it makes writing and
reading SQL a lot easier. I was told by Joe Celko once that some
psychometric research on this had actually been done at one American
university, which demonstrated the advantages of this approach. One thing I
do know from experience is that it’s a real PITA when I receive databases to
work on where naming conventions of Byzantine complexity have been used for
table and column names.

Ken Sheridan
Stafford, England

 

[Tom Lake]

I have been told that if you don't name your tables, queries, forms &
reports
like below than you did not build the db properly? Do these abbreviations
have to be put in front of the name to be policitally correct as a good
developer?


1. TABLES: tbl
2. QUERIES: qdf
3. FORMS: frm
4. REPORTS: rpt

A much more important thing is to design your tables properly! Names can be
changed easily if they are't useful but a system built on bad table design
can be very difficult to fix.

Tom Lake

 

[Ken Sheridan]

Well said, Tom, I couldn't agree more. I always tell people that the most
powerful add-in to any DBMS is a good supply of pencils and paper coupled
with the off switch on the computer. Get the logical model right and the
rest falls into place, get it wrong and you end up jumping through hoops for
ever more.

Ken Sheridan
Stafford, England

 

[Duane Hookom]

Thanks Ken. Well put. I'm stealing it for my own use... ;-)

 

[Tim Ferguson]

Do these abbreviations
have to be put in front of the name to be policitally correct as a good
developer?

Hungarian notation was firmly advocated by Microsoft engineers, at first
in the apps department where it made sense, then in the systems
department where it was corrupted beyond all usefulness, then in the user
community where it make Access and VBA into a laughing stock amongst the
resof of the professional world. Such is life. The worst offense is the
appearance of these tags in things that are not programming objects at
all, but user-visible GUI gadgets like tables and forms.

You'll be pleased to know that with the advent of dotNet, Microsoft is
taking the opportunity to disavow, repudiate, inadvocate and generally
distance itself from anything even slightly like Hungarian. About time
too. If this were the USSR, they'd be airbrushing it out of the
photographs.

If you are likely to be swapping code with MS, or with any major software
house, then you may as well get used now to the camelCase and PascalCase
conventions that are this month's de rigeur. If not, then it doesn't
matter what you do as long as you (and your colleagues) can read it
_reliably_ in nine months' time when you will have forgotten why you have
a floating point number called "intTotal".

All the best


Tim F

 

[mnature]

Another way to help yourself and others as you develop a database, is to use
[Right-Click] [Properties] to add notes to your tables, queries, forms, etc.
As you are designing a table, use the Description column to fully describe,
without abbreviations, what a particular field is for. Documentation that
exists inside the database cannot be misplaced. Even with a "proper" name,
there can sometimes be questions later.

 

[Chris Marlow]

Mell,

In Access you can now group into favourites queries/tables etc with related
functionality (certainly in XP) - which helps with documentation without
prefixes/suffixes (which is esentially the function of naming conventions).

As has been said before in the dotNet world Hungarian notation is on the way
out & camel/pascal case on the way in.

The key is no 'funny' characters & spaces in names (in case you want to
migrate to a different platform & Access sometimes corrupts queries with
spaces & slashes in).

I'd reiterate that if you want a polished product any convention you adopt
should be invisible to your users.

Regards,

Chris.

 

[Panagiotis Marantos]

I agree with What Tom has said.

I have found that people are talking and moaning about the use of naming
conventions when their databases are lacking the basic design principles.

my reccomendation to anybody who i have talked to about naming conventions
is if you want to use then is fine.

I always stress however that a good database designer should ALWAYS create a
developer's guide at the end of the project for the database which explains
the use of each object in there along with other stuff.

 

[Mell via AccessMonster.com]

Chris,

I agree.
You are correct.

Mell,

In Access you can now group into favourites queries/tables etc with related
functionality (certainly in XP) - which helps with documentation without
prefixes/suffixes (which is esentially the function of naming conventions).

As has been said before in the dotNet world Hungarian notation is on the way
out & camel/pascal case on the way in.

The key is no 'funny' characters & spaces in names (in case you want to
migrate to a different platform & Access sometimes corrupts queries with
spaces & slashes in).

I'd reiterate that if you want a polished product any convention you adopt
should be invisible to your users.

Regards,

Chris.

I have been told that if you don't name your tables, queries, forms & reports
like below than you did not build the db properly? Do these abbreviations

[quoted text clipped - 7 lines]

Any suggestions would be greatly appreicated.

 

[Mell via AccessMonster.com]

Thank you so much

Another way to help yourself and others as you develop a database, is to use
[Right-Click] [Properties] to add notes to your tables, queries, forms, etc.
As you are designing a table, use the Description column to fully describe,
without abbreviations, what a particular field is for. Documentation that
exists inside the database cannot be misplaced. Even with a "proper" name,
there can sometimes be questions later.

I have been told that if you don't name your tables, queries, forms & reports
like below than you did not build the db properly? Do these abbreviations

[quoted text clipped - 7 lines]

Any suggestions would be greatly appreicated.

 

[Mell via AccessMonster.com]

Well put

Hungarian notation was firmly advocated by Microsoft engineers, at first
in the apps department where it made sense, then in the systems
department where it was corrupted beyond all usefulness, then in the user
community where it make Access and VBA into a laughing stock amongst the
resof of the professional world. Such is life. The worst offense is the
appearance of these tags in things that are not programming objects at
all, but user-visible GUI gadgets like tables and forms.

You'll be pleased to know that with the advent of dotNet, Microsoft is
taking the opportunity to disavow, repudiate, inadvocate and generally
distance itself from anything even slightly like Hungarian. About time
too. If this were the USSR, they'd be airbrushing it out of the
photographs.

If you are likely to be swapping code with MS, or with any major software
house, then you may as well get used now to the camelCase and PascalCase
conventions that are this month's de rigeur. If not, then it doesn't
matter what you do as long as you (and your colleagues) can read it
_reliably_ in nine months' time when you will have forgotten why you have
a floating point number called "intTotal".

All the best

Tim F