naming conventions

[MP]

Hi,
Coming from a vb6 background I am accustomed to prefixing variable names to
indicate their usage.
Now just beginning to try to learn database stuff I've been lurking here and
working on my first database design.

I was noticing that I never see peoples posts here containing prefixed
object identifiers

If I had a table to contain job records I thought I'd name it tblJobs
obviously using tbl prefix to represent Table
likewise I thought I'd have fields prefixed fld,
so tblJobs would have a field, fldJobName

Since I haven't seen anything remotely like this in any of several hundred
posts I've read here lately I assume that is not a common practice in the
database world.?

Thanks for any pointers
Mark

[Anthony England]

"MP" <no****@Thanks.com> wrote in message
news:y6******************@tornado.rdc-kc.rr.com...

Hi,
Coming from a vb6 background I am accustomed to prefixing variable names
to
indicate their usage.
Now just beginning to try to learn database stuff I've been lurking here
and
working on my first database design.

I was noticing that I never see peoples posts here containing prefixed
object identifiers

If I had a table to contain job records I thought I'd name it tblJobs
obviously using tbl prefix to represent Table
likewise I thought I'd have fields prefixed fld,
so tblJobs would have a field, fldJobName

Since I haven't seen anything remotely like this in any of several hundred
posts I've read here lately I assume that is not a common practice in the
database world.?

Thanks for any pointers
Mark

You are correct - this is not used. People do use the prefix fld to mean
field but only when using vba coding with object libraries, eg Dim
fldWhatever As DAO.Field. Nobody would use it for the actual field names.
I have very occasionally seen people name the fields to indicate what data
is in them, date, long, text - but in my view that is a waste of time. Even
if you know that the field contains text, you don't the length, if required,
indexed, etc and if you tried to get your name to indicate all of that it
would be ridiculous.
I use a convention which I have seen others use, but it's not as common as
it should be. That is to make sure each field is named uniquely in the
database, and I do this by having a 3-letter prefix for all of my fields.
The big advantage of this is that when you are writing SQL, you do not need
to use TableName1.FieldName to distinguish it from TableName2.FieldName.
After trying a number of conventions, this is one that has stuck with me for
years and I still find useful. Here might be some field names from a table
of contacts:

ConID
ConFirstName
ConLastName
ConAddress1
....
ConUpdatedBy
ConUpdatedDate
If there was a related table, say tblOrder: OrdID, OrdNumber, OrdDate, etc
but needed a contact id to say who placed the order I might name this field
OrdConID. Although this might look cryptic it tells me that it is a field
in the orders table and is the foreign key for ConID. I have seen others
name their fields things like 'FkContact', but I prefer my convention.

[Keith Wilby]

"MP" <no****@Thanks.com> wrote in message
news:y6******************@tornado.rdc-kc.rr.com...

Hi,
Coming from a vb6 background I am accustomed to prefixing variable names
to
indicate their usage.
Now just beginning to try to learn database stuff I've been lurking here
and
working on my first database design.

I was noticing that I never see peoples posts here containing prefixed
object identifiers

If I had a table to contain job records I thought I'd name it tblJobs
obviously using tbl prefix to represent Table
likewise I thought I'd have fields prefixed fld,
so tblJobs would have a field, fldJobName

Since I haven't seen anything remotely like this in any of several hundred
posts I've read here lately I assume that is not a common practice in the
database world.?

Some accepted and widely used prefixes are tbl, qry, frm, rpt, txt (text
box), cbo (combo box), chk (check box), ogr (options group, the list goes on
.... OK, I made that last one up for option group, I'm not sure what the
"accepted" prefix is but prefixes are in common use and VBA code would be
just about unbuggable (IMO) without them.

FWIW, I don't prefix field names with fld unless I need to use a reserved
word such as "Date" (usually in an inherited app).

Keith.
www.keithwilby.com

[Thelma Lubkin]

Keith Wilby <he**@there.com> wrote:
: <snip>... but prefixes are in common use and VBA code would be
: just about unbuggable (IMO) without them.

So all I need to do to write bug-free code is to drop those
clumsy prefixes!!!!

sorry, but I couldn't resist
--thelma

: Keith.
: www.keithwilby.com

[Keith Wilby]

"Thelma Lubkin" <th****@alpha2.csd.uwm.edu> wrote in message
news:dr**********@uwm.edu...

Keith Wilby <he**@there.com> wrote:
: <snip>... but prefixes are in common use and VBA code would be
: just about unbuggable (IMO) without them.

So all I need to do to write bug-free code is to drop those
clumsy prefixes!!!!

Argh, un-debugabble, or something like that. It's been a long day, I'm
going home ...

[steve.minnaar]

Here's my 5c worth:

I started out writing Fortran on an IBM 1130 (16Kb RAM and 1Mb HDD)
where variable names were restricted to a maximum of 5 characters. The
letters I, J, K, L, M & N as the first character of a variable implied
an integer. The rest were implicit reals. One could override the
implicit typing by using Real Ixxx or Integer Rxxx but most users simply
stuck to the implicit convention. This did lead to strange spellings
e.g. Kount but on the other hand fitted mathematics like a glove. The
elements of a matrix were referred to as A(I,J), just as the
mathematicians expected.

As machines got bigger and BIG machines of 64Kb and even 128KB RAM
became available so these restrictions were relaxed.

Nowadays with virtually unlimited variable name length I try to be
descriptive so the variable name is immediately recognisable for what it
is. Spaces are a no no! e.g. BirthDate, FirstName, LastName, NoEntries
reads a lot better to me than dtBirthDate, strFirstName, strLastName,
intNoEntries and the type is immediately obvious. I do use Gl as a
prefix to denote global variables.

Maybe it's a case of teaching old dogs new tricks?

Thick Quinker - I just never learn.

*** Sent via Developersdex http://www.developersdex.com ***

[Albert D. Kallal]

Actually, among a lot of us developers, we do use naming conventions....

most of my tables do start with tbl, and most forms start with frm

And, reports also...

And, for variables...quite the same as VB6...

Take a look at the zillion code examples here..and will you see that for the
most part, most of the code does follow conventions.

http://www.mvps.org/access/forms/index.html

however, I don't use any conventions for field names except that all my
primary keys are ID, and foreign keys are tablename_ID

The only real rule here is to adopt something ..and stick to it...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Jeremy Wallace]

I think the vast majority of the experienced regulars here do use some
sort of prefixing. My guess is that most of the people asking the
questions are newer coders and don't yet use a naming convention, and
that the more experienced folks who are answering don't bother to
rename thing when they answer questions.

Here's a short version of the modified Hungarian that my shop uses:

Database Objects
* data access page: dap
* diagram: dgm
* form: frm
* table: tbl
* lookup table: tlkp (JDW mentioned in passing he wanted to revisit
this, I think)
* macro: mcr
* module: bas
* query: qry
* report: rpt
* stored procedure: sp
* table: tbl
* view: vw
* function: fn

Note: When placing a subform on a form, begin with the name of the
parent form, e.g., frmContacts_subLocations.

Form controls
* command button: cmd
* combobox: cbo
* frame: fra
* image: img
* label: lbl
* listbox: lst
* msflexgrid: msgrid
* option button: opt
* tab: tab
* textbox: txt

Guidelines on variables
* Declare each variable on a separate line.
* Use descriptive variable names (E.g., strFirstName, not strN)
* Add a comment explaining what each variable is used for.
* Do not use one-letter variable names. If you're doing a count,
use intCount or similar. If you're doing more than one, append a
description to each count variable.
* In Access, begin the name of each variable with a prefix
indicating its data type. (See below.)

Prefixes for Common variables
* strings: str (strFirstName)
* integers: int (intInteractionsCount)
* long integers: lng (lngContactID)
* variants: var (varShirtSize)
* booleans: bln (blnIsAdmin)
* date: dtm (dtmBirthday)
* double: dbl (dblBattingAverage)
* currency: cur (curDonationAmount)
* single: sng (sngDayOfMonth)
* global: g (gstrDatabaseName)
* module-level: m (mstrDatabaseName)

Object variables
* application: app
* connection: cnn
* control: ctl
* database: db
* file: fil
* group: grp
* recordset: rst
* sp parameter: prm
* trigger: trg
* user: usr

To extend what Keith said about ID fields, something that I've done for
a long time, phrased the way David Fenton summed it up so well once, is
to name a table for the entity described (always in the singular),
prefixed with "tbl" and the primary key of that table (I pretty much
always use autonumbers, but that's another discussion) is given the
same entity name postfixed with "ID". That way, you can always use
string manipulation to turn one name into the other, and you'll never
have to guess, or look up, what the object name or field name is.

Jeremy

[Larry Linson]

"MP" <no****@Thanks.com> wrote

If I had a table to contain job records I thought
I'd name it tblJobs obviously using tbl prefix to
represent Table likewise I thought I'd have fields
prefixed fld, so tblJobs would have a field,
fldJobName

Interesting. Most, I'd say, of the posts that use variable names use one
form or another of prefixing.

Many will write "it doesn't matter what convention you use, so long as you
use one, and follow it" but I am in strong, repeat STRONG, disagreement with
that view. Since, at the latest, Access Version 2, the most commonly used
naming convention is the Reddick Naming Convention (the Access 2.0 version
was co-authored with Stan Leszcynski {sp? Sorry, Stan}) which is documented
in detail at Greg Reddick's site, www.xoc.net/standards/default.asp . Many
of us just use the first level of that convention most of the time, but you
can get very, very detailed.

There are major advantages to using a "standard" convention such as Greg
Reddick's -- it is already created, proven by use over several versions of
the Access product, well-documented, and when you pick up someone else's
database, there's a higher probability that you're using the same
convention.

Many of the other conventions used by individuals are just what they have
"picked up" from people who do use the RNC, but don't realize that is where
their prefixes originated.

No, these are not the conventions that used to be commonly used by Microsoft
in their samples of VB -- they had at least three separate conventions used
in different parts of the company. And, no, these aren't the ones often
generated in the Access Wizards -- but, hey, we make exceptions for the
Access developers, because, after all, their "native language" is C++.

Larry Linson
Microsoft Access MVP
http://mvp.support.microsoft.com for info about MVPs

[David W. Fenton]

"Jeremy Wallace" <je************@gmail.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:

To extend what Keith said about ID fields, something that I've
done for a long time, phrased the way David Fenton summed it up so
well once, is to name a table for the entity described (always in
the singular), prefixed with "tbl" and the primary key of that
table (I pretty much always use autonumbers, but that's another
discussion) is given the same entity name postfixed with "ID".
That way, you can always use string manipulation to turn one name
into the other, and you'll never have to guess, or look up, what
the object name or field name is.

And the other thing is, if you encounter a foreign-key field with
the name PersonID, you know it stores the PK of tblPerson.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[MGFoster]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Most of your respondents on this thread seem to have missed the fact
that you are asking about tables and column names. The ISO
(International Standards Organization) has a specification on naming
database objects: ISO 11179, Information Technology - Specification and
Standardization of Data Elements. See this site for a brief overview of
this document:

http://www.gils.net/naming.html

For more info on DB naming conventions Google for "ISO 11179."

HTH,
--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQ+Ew5YechKqOuFEgEQKFGQCg3UKPFZifjC03XwhZvTkCxQ 3+OwsAoL0X
I9MOT7nkUvb9jHJ+AuxeRecV
=HxMO
-----END PGP SIGNATURE-----

MP wrote:

Hi,
Coming from a vb6 background I am accustomed to prefixing variable names to
indicate their usage.
Now just beginning to try to learn database stuff I've been lurking here and
working on my first database design.

I was noticing that I never see peoples posts here containing prefixed
object identifiers

If I had a table to contain job records I thought I'd name it tblJobs
obviously using tbl prefix to represent Table
likewise I thought I'd have fields prefixed fld,
so tblJobs would have a field, fldJobName

Since I haven't seen anything remotely like this in any of several hundred
posts I've read here lately I assume that is not a common practice in the
database world.?

[MP]

"MGFoster" <[e-mail]> wrote in message
news:Eh**************@newsread3.news.pas.earthlink .net...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Most of your respondents on this thread seem to have missed the fact
that you are asking about tables and column names. The ISO
(International Standards Organization) has a specification on naming
database objects: ISO 11179, Information Technology - Specification and
Standardization of Data Elements. See this site for a brief overview of
this document:

http://www.gils.net/naming.html

For more info on DB naming conventions Google for "ISO 11179."

HTH,
--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

Thanks to all for their input.
Yes, MG I was asking about table and column(field) naming conventions.
Thanks for that link I'll check it out.
I'll be interested to see if they name tables singularly or plurally.
Seems to be a pretty even 50/50 split in the info and posts I've found so
far on which is "preferrable".

Mark