Well my company is going through its processes of writing company standards
documents and we are at the age old question:

"Should table names be in the plural or singular forms?"

I figured that I would get a feel here for what the general consensus is
from the group.

I am from the school that says plural because the table holds multiples of
one thing. A table that holds employee information should be called
Employees.

Some of the members of the group here simply think that the table should not
be treated as holding a group of employees, but rather it should be treated
as simply a place that contains information about THE employee.

If someone can point me to a definitive standard (if one does exist) I would
be most grateful. If we are going to go one way or another I want to have
the decision documented in the appendix of the document so that when people
read this years form now there is a clear path of WHY we decided what we
did.

"Ray Cassick (home)" <raycassNOSPAM (AT) adelphia (DOT) net> wrote

From a theory standpoint, it's just a name. X and Y are as good as any other
names.

I prefer singular because it is just as meaningful as plural and usually
shorter.

On Sun, 31 Aug 2003 05:09:20 +0000, Ray Cassick (home) wrote:

I was taught that table names should be plural since a table holds
multiple rows of data and that column names should be singular since each
column in a row should contain no more than one value.

From a practical point of view I don't think it makes much difference
whether you use plural or singular for table names and column names as
long as you are consistent.

Ray Cassick (home) wrote:

First of all, let's clarify the context. Are you talking
about relational database systems?

If so, in an RDBMS a table represents a SET. The table that
holds employee information represents the set of employees.

It's always been my opinion that plural table names confuse
the set with its contents. The employees are the contents
of the set. They are many, so they are plural. But the set
itself is singluar. There is only one set of employees -- the
employee set is a set of employees. Confusing a set with the
contents of the set is akin to confusing a table with a row.

Since the table name refers to the table, and the table is a
set, and the set (not the contents, but the set itself) is
singular, then the table name should be singular.

I don't know if one exists. I think it's mainly a religious
argument. However, I don't think I've ever seen my argument
above debunked.


Larry Coon
University of California
larry (AT) assist (DOT) org
and lmcoon (AT) home (DOT) com

"Larry Coon" <lmcoon (AT) nospam_cox (DOT) net> wrote


WHY to go singular.

standard set otu for this yet. There is for practiclly everythign else.

"Ray Cassick \(home\)" <raycassNOSPAM (AT) adelphia (DOT) net> wrote

Joe Celko that discussed table & column names (amongst other things) -
don't have the link to hand, but it was a discussion about table
design.

I would tend to the singular though, as reading the relation as a
predicate makes more sense to me that way (e.g. for a relation of
candidates with attributes scn, forename and surname the relation
could be read as "there is a candidate with candidate number scn,
whose first name is forename and whose family name is surname"). With
a plural, it would have to read as something like "there is a set of
candidates each of whom has ..." which is a bit more long winded. (The
other plural reading, "there are candidates with..." makes no sense
for a relation.)

Utterly informal, like all rules of thumb, prejudices, etc. etc. !

- Tony

"Ray Cassick (home)" <raycassNOSPAM (AT) adelphia (DOT) net> wrote

The problem is not a lack of standards. The problem is too many standards.
Both standards exist and both have arguments pro and con.

As I mentioned ages ago, from a theory perspective, the name is unimportant.
Its only function is to name. Any contextually unique symbol will do. From a
theory perspective, X and Y are as good as any other name as is any
meaningless sequence of characters like A62Y32HPQ3.

Apparently, Larry did not recognize the debunking of his argument.

Arguments for and against different conventions amount to aesthetic
arguments. Since aestheticism resembles religion in requiring no rational
justification, aesthetic arguments resemble religious arguments. There is no
accounting for taste.

That said, I like Tony Douglas's suggestion to choose a convention to
encourage people to think of relations in terms of the predicate calculus
because I find that specific cognitive bias the most revealing one. Others
will like other suggestions because the they find other things appealing.

Any claim to have an objective argument for one's prejudices and preferences
is bunk.

"Ray Cassick (home)" <raycassNOSPAM (AT) adelphia (DOT) net> wrote


For what it is worth, my rather strong belief is that attributes should be named so
that they capture as far as possible the tuple predicted.

For example, in
http://www.hughdarwen.freeola.com/Th...hout-nulls.pdf
Hugh Darwen has a table called PERS_INFO with attributes {Id, Name, Job, Salary}and
suggest this predicate as the meaning of any tuple in the table

The person identified by Id is called Name and has the job of a Job, earning Salary
pounds per year.


I belive that these rather wordy predicates should be approximated by the attribute
names. In the above example I would suggest naming the attributes to

{ Person_Id, Called_Name, Does_Job, Earns_Salary }

Later on Hugh shows two more tables SALARY_UKN and UNSALARIED both with one attribute
named { Id }. By my scheme, these attributes would be more resonable be name
{Person_with_unk_salary} and {Unsalaried_Person }respectivly.

Now, what has this got to do with table names I hear you ask? Well the answer (for
me) is that a table name should seen as little more than a short hand for the tuple
predicate of that table. In the case at hand, PERSON_INFO is not a bad name (IMO)
for the (highly non gramatical) sentance "Person_Id Called_Name Does_Job
Earns_Salary". PERSON on it's own would also be ok(ish). What would not be good
(as a name for a predicate) is any Plural name. PEOPLE_INFO, or INFO_ABOUT_PERSONS,
or just plain PERSONS or PEOPLES are all not good.

So, to sum up, if you happen to feel the need to give a table a name, use one that is
suggesting of the predicate and that will be a singular name.


Regards
Paul Vernon
Business Intelligence, IBM Global Services

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

That depends on where you draw the theory line in the sand. If you are interesting
only in say the mathamatics of relational algebra, then indeed the names are not very
important, but even then 'X' would be prefered to say 'XAS$%£^AF"sgrSFPI' by most.

If you prefer to not draw a line between the theory and the practical, then there is
no reason why a 'theory of names' cannot be considered. Such a theory would surly be
able to tell us that

{ Loves, Loved }

would be better attribute names than

{ X, Y }

or

{ Cabbage, Potato }

and certain much better than

{ Hates, Hated }

for a tuple purporting to represent predicates of the form

"Juliet loves Romeo"

Regards
Paul Vernon
Business Intelligence, IBM Global Services

"Paul Vernon" <paul.vernon (AT) ukk (DOT) ibmm.comm> wrote

Sorry, that should have been 'tuple predicate'