sullivan@aqdata.uucp (Michael T. Sullivan) (01/17/90)
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, CAjsc@sequent.UUCP (J. Scott Carr) (01/17/90)
In article <1990Jan16.170217.16718@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes: >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@bbxsda.UUCP (Scott Amspoker) (01/18/90)
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". >[example deleted] 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@utzoo.uucp (Henry Spencer) (01/18/90)
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"... > > 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 henry@zoo.toronto.edu
mh@awds26.eaton.com (Mike Hoegeman) (01/18/90)
>In article <1990Jan16.170217.16718@aqdata.uucp> sullivan@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.
itkin@mrspoc.Transact.COM (Steven M. List) (01/18/90)
sullivan@aqdata.uucp (Michael T. Sullivan) writes:
Asking about naming conventions for columns within tables in a database.
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}!itkin@guinan.Transact.COM :datanguay@watmath.waterloo.edu (David Adrien Tanguay) (01/18/90)
In article <1990Jan17.194804.15864@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <1990Jan16.170217.16718@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes: >> plain descriptive table/structure descriptive >> ----------------- --------------------------- >> name cu_name > >Personally I see no reason for the prefixes any more; I'll go with the >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@utzoo.uucp (Henry Spencer) (01/19/90)
In article <33341@watmath.waterloo.edu> datanguay@watmath.waterloo.edu (David Adrien Tanguay) writes: >My reason for using the table/structure descriptive style is to help >me follow the chain of types in an expression... >Given that I know the prefixes, they make the expression a little more >readable for me... 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. -- 1972: Saturn V #15 flight-ready| Henry Spencer at U of Toronto Zoology 1990: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
lew@gsg.UUCP (Paul Lew) (01/19/90)
sullivan@aqdata.uucp (Michael T. Sullivan) writes: > 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 (lew@gsg.gsg.com) UUCP: oliveb---+ uunet---samsung--+ General Systems Group, 5 Manor Parkway harvard--+--gsg--lew Salem, NH 03079 (603) 893-1000 decvax---+
larrys@sequent.UUCP (Larry Scheurich) (01/20/90)
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
jkrueger@dgis.dtic.dla.mil (Jon) (01/21/90)
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. 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 jkrueger@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@targon.UUCP (Ruud Harmsen) (01/22/90)
In article <27885@sequent.UUCP> jsc@crg4.UUCP (J. Scott Carr) 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 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.