Re: Long column names...Performance issues?

"chenthorn" <carlhe_at_hotmail.com> wrote in message news:6f87ba84-7922-4965-8ebe-a8e7a213e8ee_at_d42g2000prb.googlegroups.com...
> My group is working to create a new set of Db standards as we embark
> upon redesigning our new web app backend db. The other architect wants
> every table/column/variable name to be unabbreviated and as
> descriptive as possible. This of course leads to long and ungainly
> names. while this is all well and fine in theory, when writing a lot
> of code, long column names are no fun and often lead to bugs due to
> spelling errors (Not that I would know anything about that )
>
> I would like to hear from the community what you all feel are best
> practices regarding naming conventions, and how they affect your
> environment.
>
> Thanks in advance!

All I can say is "Waaah!" If the variable names are descriptive, it's easier to read code in order to figure out what it does. The only bugs that long names cause are the ones that are easiest to find: In most languages it causes a compiler error (or can if the right options are selected). It's a lot harder to find a problem when the column name is PDATE and you don't know whether PDATE is for Date Purchased or Date Picked. What makes it worse is when names are reused or code is combined and the comments that tell you what PDATE is for aren't updated. I would much rather spend a few extra seconds keying in a long and descriptive name than several extra hours trying to figure out what a piece of code is supposed to do or several extra days trying to chase down a bug. Received on Wed Nov 19 2008 - 22:11:05 CET