Re: Long column names...Performance issues?

On Nov 20, 12:29 pm, chenthorn <car..._at_hotmail.com> wrote:
> On Nov 19, 3:57 pm, toby <t..._at_telegraphics.com.au> wrote:
>
>
>
> > On Nov 19, 12:29 pm, chenthorn <car..._at_hotmail.com> 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).

Not measurably.

> 3. XML output bloated when names used as tags.
> 4. Bloats data packet size when result set sent to client.
>

I find it impossible to believe any of this would have a measurable impact.

Forget all speed and latency issues and focus on maintainability, where you can really make a difference. This thread shows that microoptimisation  is already costing you money and time!

> 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 - 21:16:42 CET