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_at_emjay.com ==> Kyrie eleison <==
>
> Fight spam by joining CAUCE - Coalition Against Unsolicited Commercial Email
> http://www.cauce.org/
Received on Sat Mar 07 1998 - 00:00:00 CST