Table Names

  • Thread starter Thread starter Steve
  • Start date Start date
S

Steve

I'm wondering about naming tables. Should they be plural? Is there a
standard? Should I name a table Income or Incomes? Should I name a table
lease or leases?
TIA
Steve
 
The standard naming convention is to begin all table names with "tbl", try to limit the name to 25 characters or less and not use any blank spaces or dashes. Other than that, use a name that will be easiest for you and that will reflect the data in the table. Singular or pural in the name doesn't matter to Access so go with the actual data - does your lease table contain information for one lease or many

Hope this helps

Howard Brod



----- Steve wrote: ----

I'm wondering about naming tables. Should they be plural? Is there
standard? Should I name a table Income or Incomes? Should I name a tabl
lease or leases
TI
Stev
 
Steve,

Whatever works for you is fine, in my opinion. Different people use
different naming conventions. For eample, for some strange reason some
people put tbl in front of the names of all tables. The main things to
avoid, in my opinion, are:
- naming a table (or field) with a 'reserved word', e.g. Date or Name
- the use of non-alpha or non-numeric characters, such as # or ()
For more information on these, see http://support.microsoft.com/?id=209187
 
I tend to be a little sloppy on the singular/plural issue myself.

However, from a theoretical persective, a table is a collection of entities,
each represented by a single row of information. In that light, a table
should be named in the plural. Thus "tblCustomers" rather than
"tblCustomer". By the same token, fields should hold one and only one piece
of information at a time, so they are named in the singular: FirstName or
OrderNumber.

From a practical standpoint, it matters very little. More important is the
issue of properly prefixing database object names and variables. There are
several standards out there: Lyzinski, Reddick, Hungarian, etc. Pick one.
 
However, from a theoretical persective, a table is a collection of entities,
each represented by a single row of information. In that light, a table
should be named in the plural. Thus "tblCustomers" rather than
"tblCustomer".
Click to expand...

Using that approach, you will never have a table whose name is not plural.
(Unless, you have a table which, by design, contains only one record.) That
approach is providing no additional information by the use of the plural.

I already know that a table contains a collection of records. I want to know
what one record in that table represents.

My approach (the correct approach! ;-) ) is to name the table so that it
indicates what one record represents. Thus a table containing employee records
would be named Employee table. One record represents one employee.


In any event, I feel it's important to be consistent in your naming
conventions, whatever those conventions may be.
 
You make some good points. The singular/plural distinction is not
something I have taken too much notice of before, so just for fun I
checked out the database I am working on today. Of my 92 tables, 52
have plural names, 39 singular, and 1 (Series) ambiguous. I tend to
think of the name of the table in terms of what it is "about" rather
than the identity of each record it contains. So I have Participants
and I have Participation. I have Bookings and I have Waitlist. I can't
see there can be any "right or wrong" about this. The approach I use
works for me, which is good. Others take other apprtoaches, which work
for them, but wouldn't work for me, which is also good.
 
Steve

Having a consistent naming convention makes it easier for you to go back and
figure out what you were doing, and easier for anyone else who inherits your
applications.

The Leszynski and/or Reddick and/or ???? naming conventions are available to
save you having to invent your own, with the benefit of being more widely
known.

I use a variation (personal, but consistent), using descriptive prefixes for
higher level objects (tables, queries, ...) and for controls on forms and
reports, but not to the level of field names in tables. For me, seeing
"tblPerson" and "tlkpState" reminds me that I've treated Person as a main
table and State as a lookup table. And qryState and qappNewPerson tells me
that the first query lists States, while the second appends Persons.
 
I've been thinking about this a little more and I'd like to elaborate on my
previously-stated bias towards using singular for table names.

In a non-database language/environment you can give different names to the file
and the record. In that case, I do consider using plural for the file names,
for instance Employees file, since it is a file of employees. (Actually, I'd
probably call it the Payroll Master file, but this is just an example.)
However, I define an Employee record (using singular) because any record
applies to only one employee.

However, in a database environment (at least with Access and some other dbs),
the table and the record share the same name. So, whichever you choose -
singular or plural - that's what you're using to name both the table and an
individual record.

If you name the table using plural then you're going to be stuck with that
plural name when referring to a single record. If you name the table
Employees, then when you refer to a single record (or a field in a single
record) you're going to have to use that plural name, as in
Employees.FirstName. In that case, you are referring to the FirstName of one
single employee, yet you are using plural. Having to use plural (Employees) in
that context grates on my psyche like a fingernail across a black board!

That 'problem' can be resolved by using singular when naming the table, and
without creating any other real or imagined 'problems'.

Rick
 
Rick,

You bring up some very good points and I don't disagree. In fact, I agree
completely. I dashed off my answer hastily and wasn't completely clear.
Since we are elaborating, I hope you'll indulge me.

One semester a year, I teach a database design course at a local college. I
have discovered over the years that the longer I keep the students in the
theoretical, the better their database designs will be. In Access, it is
so easy to create tables, they have a tendancy to dive right in without
thinking. So even though Entities and Tables are essentially the same, I
try to keep them distinct as long as possible.

I am right in the middle of my semester right now, so when Steve asked about
tables, I was thinking Entities.

From an Design perspective, I like to refer to Entities in the plural and
Attributes in the singular. This points out that entities are groups of
things (this box represents all of my customers) whereas attributes
represent a single piece of information about the entity. One benefit of
this is that if you have an attribute that is plural (ie children) then you
know that it is not really an attribute, but an entity itself.

So while an ER Diagram may look like this:

---------------- --------------
| Customers |-----< | Orders |
---------------- --------------

This will be read as
"Each Customer may place One or More Orders and Each Order must be for One
and Only One Customer."

The diagram shows the group of entities, but the sentence refers to
individuals within the groups.

I said I was a little sloppy about singular/plural naming, but in looking
over the design documents of my projects, I find that while I refer to them
in the plural in my ER Diagrams (Customers), most often I refer to them in
the singular when I implement them (tblCustomer).

I've never noticed this disparity before. Thanks for helping me to clarify
my thinking.

--Roger Carlson
www.rogersaccesslibrary.com
 
Back
Top