Xref: utzoo comp.databases:4729 comp.lang.c:25292
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!rice!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!larrys
From: larrys@sequent.UUCP (Larry Scheurich)
Newsgroups: comp.databases,comp.lang.c
Subject: Re: How do you name table/structure elements?
Message-ID: <28010@sequent.UUCP>
Date: 19 Jan 90 18:55:03 GMT
References: <1990Jan16.170217.16718@aqdata.uucp>
Reply-To: larrys@crg4.UUCP (Larry Scheurich)
Organization: Sequent Computer Systems, Inc
Lines: 50

In article <1990Jan16.170217.16718@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes:
>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.
>
>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.              sullivan@aqdata.uucp
>San Dimas, CA

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