How do you name table/structure elements?
Michael T. Sullivan
database table rows or C structure elements. As far as I can tell,
there are two camps: the "plain descriptive" and the "table/structure
descriptive". Let me give an example: supposed you have a
table/structure called "customer". Its elements can be named two ways
plain descriptive table/structure descriptive
----------------- ---------------------------
name cu_name
address cu_address
city cu_city
state cu_state
zip cu_zip
...and so on.
I can see arguments for both but I'd like to find out what the rest
of the world thinks about this. One reason is curiousity but another
is that our company is trying to come up with certain standards for
employees to follow and this may be one of them. Before making any
decisions we'd like to hear different viewpoints. Feel free to either
send me mail or debate on the net. Both will be helpful. Thank you.
--
Michael Sullivan uunet!jarthur!aqdata!sullivan
aQdata, Inc. sull...@aqdata.uucp
San Dimas, CA
J. Scott Carr
>I can see arguments for both but I'd like to find out what the rest
>of the world thinks about this. One reason is curiousity but another
>is that our company is trying to come up with certain standards for
>employees to follow and this may be one of them. Before making any
>decisions we'd like to hear different viewpoints. Feel free to either
>send me mail or debate on the net. Both will be helpful. Thank you.
My preference is to prepend text that identifies the object the
column belongs to. The intention is that the core of the field name
represents the attribute, the prefix the object. This is most important
with keys. For example, part number in a parts table and a orders table
are the same attribute. Naming the columns PRT_PARTNO and ORD_PARTNO
helps clarify complex selects and joins, as well as the data dictionary.
--------
Scott Carr uunet!sequent!jsc
Sequent Computer Systems (503) 526-5940
Scott Amspoker
>database table rows or C structure elements. As far as I can tell,
>there are two camps: the "plain descriptive" and the "table/structure
>descriptive".
I've seen a lot of older code that used "table/structure descriptive" field
names. This is probably because old C compilers did not keep seperate
name spaces for field names. Therefore, if you had a field called "len"
that appeared in several different structures you would probably have
to make it unique somehow. Today's compilers are a little smarter
and a I prefer to let the structure variable (or pointer) itself act
as the "qualifier".
--
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232
unmvax.cs.unm.edu!bbx!bbxsda!scott
Henry Spencer
>database table rows or C structure elements. As far as I can tell,
>there are two camps: the "plain descriptive" and the "table/structure
>
> plain descriptive table/structure descriptive
> ----------------- ---------------------------
> name cu_name
One thing to bear in mind is that the cu_name practice is to some extent
a historical accident. Once upon a time (in a galaxy far far away :-))
all struct members lived in a single common name space, so it was vital
to make the member names in different structures different. This is how
the prefix-with-an-abbreviation-of-the-struct-name convention arose.
Personally I see no reason for the prefixes any more; I'll go with the
plain descriptive style now.
--
1972: Saturn V #15 flight-ready| Henry Spencer at U of Toronto Zoology
1990: birds nesting in engines | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Mike Hoegeman
I don't claim any rights to being to being a database expert but I've
had some experiences with this kind of naming scheme in the last
project I worked on. We had someone in our group who set up tables
with column names like this and when all the pluses and minuses
where weighed it was a real bad idea.
At first glance this naming scheme sounds good and that's what i
thought too at first. It makes things a tad easier on the database
definer-maintainers, but for someone who actually uses the thing in
applications which are more complex than a simple business application
it does'nt have much merit. It makes things like database browser
programs almost useless when they could in fact be a very powerful
application. In cases such as these you want to do the exact opposite
of the the previous posters suggestion. You want to try to make every
effort to give columns of the same basic flavor the SAME
name. This lets you do things like look for the name 'johnson'
throughout an entire database fairly easily if you give call all the
columns throughout the database that hold names "NAME"
If you want to clarify a complex statment , most query languages let
you prepend the table name onto the front of a column name. Use that to
define what table the column is from. If the parts table
name is PARTS Express PRT_PARTNO instead as PARTS.PARTNO and use
ORDERS.PARTNO instead of ORD_PARTNO.
Things are even worse when you give the prefix a
quasi-crytic name. Looking at "ORD_PARTNO" on it's own does'nt give
much of a clue that the column is in the ORDERS table.
In my opinion, the best thing you can do for "naming conventions"
is
- give your tables a descriptive name as possible without
getting into the "company_employee_information_table" type
naming syndrome.
- try to keep your column names as **generic** as possible
don't try to give the name any type of table context . a program
or interactive user may not be accessing that column (at first)
by way of the table name, they may be fishing around using the
data dictionary. if you keep your names generic it will help them
quite a bit.
Steven M. List
I prefer to use a descriptive name that is deliberately the same across
all tables in which the field appears. That is, if I have a customer
ID that appears in several tables, I will call it customer_id in all
those tables. On the other hand, I would NOT call it "ID", since that
does not tell me what it is.
In Michael's example, he had a field called "name." I would never use
a simple field name like that, because it doesn't tell me what it is.
On the other hand, customer_name is quite descriptive and lets me know
what the field is (and what the connection is) no matter which table
it is in.
--
+----------------------------------------------------------------------------+
: Steven List @ Transact Software, Inc. :^>~ :
: Chairman, Unify User Group of Northern California :
: {apple,coherent,limbo,mips,pyramid,ubvax}!it...@guinan.Transact.COM :
David Adrien Tanguay
>In article <1990Jan16.1...@aqdata.uucp> sull...@aqdata.uucp (Michael T. Sullivan) writes:
>> plain descriptive table/structure descriptive
>> ----------------- ---------------------------
>> name cu_name
>
>plain descriptive style now.
My reason for using the table/structure descriptive style is to help
me follow the chain of types in an expression.
E.g.,
expr->n_left->n_type->ty_sym->sy_name
Given that I know the prefixes, they make the expression a little more
readable for me since the types of the subexpressions can be inferred
from the element names.
David Tanguay
Henry Spencer
>My reason for using the table/structure descriptive style is to help
>Given that I know the prefixes, they make the expression a little more
I *tend* to feel that if expression readability has become a problem,
there are deeper difficulties present, like poorly-named fields or poorly-
designed code. That is, trouble in keeping track of what's going on is
just a symptom, and understanding and curing the underlying problem -- why
is the code so hard to follow? -- is better than slapping on a syntactic
bandaid.
Paul Lew
> plain descriptive table/structure descriptive
> ----------------- ---------------------------
> name cu_name
I would like to point this out: if you are going to us the 'plain descriptive'
approach, make sure you have a set of 'modern' tools to work with them. For
example, you can not simply do grep on 'name' because all the other 300 'name'
used in other structures will also be found. A lot of other tools will not
function nicely, to name a few: mkid/gid, cxref. People worked with Ada
before probably feel the same.
Put some burden on the programmers will always make life a lot easier. If
you are working with Unix and you have Saber C, you might be OK. This is not
true if you are cross compiling for MSDOS.
IMHO, I think put some 'smart' in the variable naming convention is a good
idea. The other one I like is to Capitalize all the global variables so
when you look at the code you 'know' what the implication will be...
--
Paul Lew (l...@gsg.gsg.com) UUCP: oliveb---+
uunet---samsung--+
General Systems Group, 5 Manor Parkway harvard--+--gsg--lew
Salem, NH 03079 (603) 893-1000 decvax---+
Larry Scheurich
I support the Oracle Financials products, and have found they're naming
scheme to be quite self-explanatory. What they do is prefix each table
by a product code. Here's a sample (not from the financials, so I don't
give away any of their secrets). If I have a table that contains parts
called PART owned by user PRT, and a table that contains a list of
customers called CUSTOMER owned by user CST, here is how it would
be handled:
A part number column in the PART table would be called PRT_PART_NUMBER.
User CST would have select, insert, update, delete access on the table.
User PRT would first grant the accesses to CST, and then would create
a synonym PRT_PART (same as the column name) that refers to PRT.PART.
User CST would use the synonym PRT_PART to reference the table throughout
the application. The prefix helps to identify that the table is owned
by someone other than user CST. It takes a lot of confusion out of
knowing who owns a table in a very complex application (like the financials).
Just my thoughts!
--
Larry Scheurich uunet!sequent!larrys
Sequent Computer Systems (503)-526-4240
Beaverton, OR
Jon
>I would like to get some feedback as to how and why you name your
>database table rows or C structure elements. As far as I can tell,
>there are two camps: the "plain descriptive" and the "table/structure
>descriptive". Let me give an example: supposed you have a
>table/structure called "customer". Its elements can be named two ways
> plain descriptive table/structure descriptive
> ----------------- ---------------------------
> name cu_name
> address cu_address
> city cu_city
> state cu_state
> zip cu_zip
> ...and so on.
What you're calling the table/structure descriptive is a symptom of
impoverished namespace tools, or someone's exposure to the same in
previous work. Query languages can name columns unambiguously using
classic structure.member syntax. Nothing is added by the redundancy.
Consider:
select cu_name from customer
select * from customer, locations where cu_name = lo_name
Versus:
select name from customer
select * from customer c, locations l where c.name = l.name
Anyone see any advantage of the first form?
-- Jon
--
Jonathan Krueger jkru...@dtic.dla.mil uunet!dgis!jkrueger
The Philip Morris Companies, Inc: without question the strongest
and best argument for an anti-flag-waving amendment.
Ruud Harmsen
>My preference is to prepend text that identifies the object the
>column belongs to. The intention is that the core of the field name
>represents the attribute, the prefix the object. This is most important
>with keys. For example, part number in a parts table and a orders table
>are the same attribute. Naming the columns PRT_PARTNO and ORD_PARTNO
>helps clarify complex selects and joins, as well as the data dictionary.
I disagree. Especially in the data dictionary this won't clarify things,
but rather mistifies them, because it won't be clear that most of what
you could describe about PRT_PARTNO is also valid for ORD_PARTNO, unless
you duplicate the description, or maintain pointers in the text.
I think PARTNO is the "data element", and should therefore be the basis
for the datadictionary. PARTNO as occurring in ORD and PRT are "data items".
I think that it is superfluous to prepend anything, because both in the
programming language and in the database query language a reference to
the object is already there:
- E.g. in C, you would have a structure type corresponding to the object.
so you write: prt.partno and ord.partno (or something similar with ->)
- In SQL, the join can be done with something like:
... WHERE PRT.PARTNO = ORD.PARTNO
where PRT and ORD identify the tables, and PARTNO the attributes.
T. William Wells
Initially, I did this because my code had to work even with
ancient compilers. However, even though I now write code that
mostly does not have to have that degree of portability, I still
do.
There are three distinct reasons. The first is that the prefix
contains typing information which becomes available to the reader
of the code; this can make reading the code easier.
Another reason is that I often have need to determine all
references to a particular structure member. If several
structures have the same field name, this gets tricky.
A final reason is that I try to arrange that names of different
flavors are visually distinct. Thus names of the form `a_b' where
`a' is some kind of acronymic thing rather than a word are, in my
code at least, generally structure fields. This kind of visual
distinctiveness contributes to the general readability of the
code.
---
Bill { uunet | novavax | ankh } !twwells!bill
bi...@twwells.com