Creating and using Descriptive and Meaningful Field Names in your
Database Design:
A field in your database represents a characteristic of the subject
of the table to which it belongs. If the field is appropriately named
it should be easy to identify the characteristic that the field is
supposed to represent. If a field name is ambiguous, unclear or is
vague it may suggest that the purpose of the field is not fully identified.
How should you create Database Field Names
- Define a unique, descriptive name that is meaningful to
the organisation. The field name should only appear the
once in the entire database; the exception to this rule being when
the field serves to establish a relationship between two tables.
Ensure that the field name is descriptive enough to convey its meaning
to everyone who views it.
- Define a name that accurately and clearly identifies the
characteristic that a field represents. Using "Contact
Phone Number" is an example of an inaccurate, possibly ambiguous
name. Which type of contact number does this field represent: Home
Phone, Work Phone, Mobile Phone? This needs to be more specific.
If we need to store each of these numbers, we will need to create
"Home Phone", "Work Phone" and "Mobile
Phone" number fields.
We may at times, need to resolve generic field names, such as "Address",
"Town" and "County" by using an appropriate table
name as a prefix for the field name. If you have information on both
Employee and Suppliers for example you should consider naming fields
using "EmpAddress" or "SupAddress" to define which
set of data that these fields belong to.
- Try to use the minimum amount of words to portray the
meaning of the characteristics that the field represents.
If possible, you will want to avoid lengthy field names, however
it is also best to avoid using single words as a field name if that
word will not sufficiently define the field. For example, if you
are wanting to record the date when an Employee joined the company,
"Hired" is probably too short (an vague) and "Date
That The Employee Was Hired" is too long! "DateHired",
however, is a far more appropriate and accurate representation of
the field characteristics.
- Don't use acronyms, and use abbreviations with caution.
It can be particularly difficult for a user who may not be fully
aware of the system to understand the acronyms that may have been
used. Fields named "GST_RT" could be extremely misleading,
and the user may find these hard to determine the characteristics
of the field. You may use abbreviations, although use them sparingly,
and only use them where they may supplement or enhance the field
name in a positive manner.
- Do not use names or words that may confuse the meaning
of a field name. Ensure that the field name does not contain
redundant words that would make the field names meaning unclear
or could possibly lead to the field name being misunderstood. Use
words or names that would provide the most meaningful description
of the field characteristic within the organisation.
- Ensure that you do not use field names that implicitly
identify more than one possible characteristic. It should
be possible to identify the problems here by seeing words such as
"and" or "or". Field names that also include
characters such as (\) or (&) will lead you to problems. If
you see a field named "Town or City" or "Phone\Mobile\Fax"
then you will need to be looking at creating new fields to split
these characteristics.
- Use the singular form of the name for a field characteristic.
A field with plural names, such as "Subjects", "Lessons"
etc. implies that the field may contain multiple values for a single
record. A field name should be singular as it should represent a
single field characteristic of the subject of the table to which
it belongs. A table name, on the other hand, can be plural as this
represents a collection of similar objects or events. When using
correct database naming conventions, you should easily
be able to distinguish between table names and field names.