Re: Long column names...Performance issues?

From: chenthorn <>
Date: Thu, 20 Nov 2008 09:29:54 -0800 (PST)
Message-ID: <>

On Nov 19, 3:57 pm, toby <> wrote:
> On Nov 19, 12:29 pm, chenthorn <> wrote:
> > 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.
> There is no impact on performance whatsoever, so you are free to
> choose whatever naming convention makes your code most writable,
> readable and maintainable.
> > Thanks in advance!- Hide quoted text -
> - Show quoted text -

Thank you all for your (mostly) helpful information. It would seem that the consensus is that long table\variable\column names are no hinderence to performance. I have to say that the only examples of where it may become an issue are very few, and probably taken care of in katmai, although I am not sure.
Here is what i found AGAINST long names: 1. Long names take up more room inside dynamic sql strings, forcing authors to perform various workarounds. (not really a performance issue, but an issue to coders anyways)
2. Longer names increase query parsing time. (probably not enough of a bump to be noticable, but testing would be interesting, especially if sproc has numerous recompiles).
3. XML output bloated when names used as tags. 4. Bloats data packet size when result set sent to client.

As I said, these issues are ones that I found through searching the internet. I would be interested in hearing any feed back. Thank you all again in advance! Received on Thu Nov 20 2008 - 18:29:54 CET

Original text of this message