|
When you
create a database you should have a standard naming
convention in mind. Conventions will vary by product, vendor, and
most importantly perhaps, your company or organization. What follows
is one that is common in the Microsoft Access community.
General
Principles
Names should
be concise but meaningful. Whenever practical avoid abbreviations.
Isn't LastName better than lName or maybe sName(surname)? Believe me
this can be very helpful. You won't have to remember later just what
arcane abbreviation you chose. On the other hand don't get
ridiculous. EmployeeID or EmployeeNo will do just fine. You don't
need to write out EmployeeIdentificationNumber.
Do not include
any spaces in your names. Use a convention which capitalizes the
separate words or separate them by an underscore. Like so:
last_name
LastName
Yes, Access
will accept names with spaces by enclosing them in square brackets.
For example: [Last Name]. But this can cause maintenance problems
later. You don't want to have problems with a query because it can't
recognize you meant the same thing by [Last Name] with two spaces and
[Last Name] with one. This won't happen often but when it does it
will be at the precise time you are under pressure to get a report
out for management. Don't use spaces and you won't have this problem.
Prefixes
Access object
names are typically prefixed with three characters that denote the
type of object. This makes the type of object easy to spot in the
expression builder, etc. What follows are the prefixes by object.
Database
First, give
your database a meaningful name which relates to the application.
Something like ShopControl or EmployeeBenefits. Not db1.
Tables
Table names
should be meaningful to the application whenever possible. If for
example you are setting up a database for a kennel you may want
tables for dogs and breeders, not products and suppliers. An overdone
example, perhaps, but I have actually seen this one! |
Tables (Cont'd)
Table names
should be plural where it makes sense. I.e., employees, customers,
products, etc. Many Access people prefix the name with tbl like so: tblEmployees.
Field Names
Use a meaningful name as discussed under general principles. As well you may want to prefix the name to reflect the table that houses it. Example: empFirst_name in an employees table. This convention is used by some database textbook authors but is by no means universal. Make your own decision on this. Note that fields placed in a child table as a foreign key do not take this prefix but retain their original spelling.
Queries
Prefix query
names with qry as shown below.
qryLaborDetail
If you like
add an underscore. (This applies to other object names as well.)
qry_LaborDetail
Forms
Use frm.
Example: frmWorkOrders. Subforms can be be prefixed with the four
characters: sfrm. Some people use frmsub.
Reports
Use rpt.
Example: rptLaborSummary. As with forms, subreports can be prefixed
with srpt or rptsub.
Macros
Use mcr.
Example: mcrCreateLaborHistory.
Controls
There is a
complete set of conventions for controls, too. You should always name
your controls explicitly if you will refer to them in code. It is not
very clear what you mean when your VBA code reads text01 * (text12 + text18).
The
conventions vary a bit. Some of the most common are: txt for text
boxes, cmd for command buttons, cbo for combo boxes. You can view the
well known and very detailed Leszynski & Reddick Access Naming
Conventions here. |
