How do you name table/structure elements?
Mike Hoegeman
mh at awds26.eaton.com
Thu Jan 18 08:18:48 AEST 1990
>In article <1990Jan16.170217.16718 at aqdata.uucp> sullivan at aqdata.uucp (Michael T. Sullivan) writes:
>
>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 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.
More information about the Comp.lang.c
mailing list