Re: Naming Convention for Columns

i work in a 'c' shop. we are converting a ibm series/1 for you moldy oldies! application to c with db2. our standard is all caps with underscores MEDIA_DATE when we select a column from the db we move the column to a structure which is the table name TRANS_DETAIL.MEDIA_DATE this keeps any command line queries from adding to my carpal tunnel ; ) like some others have said, always use num or nbr or whatever you decide another thing we did was designate _FLAG as an 0 or 1 field and _CODE as 1,2,5,a,b,c ect have fun, elaine Dave Mullen wrote: > Hello all, > > We are setting up new database naming conventions, and I'd like to > hear other people's thoughts on what they consider to be important > considerations. > > In particular, I'd like to know how people feel about prefixing the > names of columns in a relational data base with a short prefix > representing the table to which the column belongs. (Foreign keys > would retain the prefix of the foreign table, i.e., the table being > referred to. This would also be true for denormalized, redundant data: > the redundant columns would carry the prefix of the "owner"/master > table.) The lead developer for this project is strongly in favor of > using such prefixes; they were used here in the past in the DBAM data > base being replaced. He likes not having to specify the name of the > table when he mentions the column in code, and also feels that the > prefix helps remind the developer/user of which table they're working > with. > > I prefer not to use such prefixes. The reasons I have given are: > > 1) It's redundant. If a column exists on more than one table and the > reference is ambiguous, use "table.column". It also actually makes the > column name longer than necessary. > 2) When the same column appears on more than one table, it should have > the same name. This is clearer to users (both end users and > developers), and many query-building tools will infer relationships > based on column names which match, which can be very helpful. > 3) Views should not have to rename all the underlying columns, which > they would need to in order to adhere to the standard. > 4) Having columns on one table carry the prefix of another table is > confusing (except perhaps in the case of foreign keys). > > What other arguments can be made for or against these column prefixes? > > BTW, our primary development data base is Sybase, but we have (and > will have, I'm sure) others (Oracle, MS Access, et al); I'd like to > address this globally. > > Thanks! > > -------------------------------------------------------------------------- > David Mullen *** Any opinions expressed are mine, and not *** > Emjay Corporation *** necessarily those of Emjay Corporation. *** > Milwaukee, WI > dave.mullen@emjay.com ==> Kyrie eleison <== > > Fight spam by joining CAUCE - Coalition Against Unsolicited Commercial Email > http://www.cauce.org/