Re: Long column names...Performance issues?

chenthorn wrote:

> 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:
[snip]

> 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).

I will bet you a fancy dinner that the time needed for just one additional disk I/O operation would swamp this cost. There are really just three things to think about: lock-contention, disk I/O, and network I/O. These are many orders of magnitude slower than parsing and doing symbol table lookups. (In any case, backtracking to disambiguate SQL can take a long time in the parser, as can re-writing where-clauses in conjunctive normal form. And then there is query optimization too.)

If you can tell me you've reduced these WAY below "good enough" then I will agree you could spend your free time tinkering with testing the parsing time conjecture. And then you can buy me my fancy dinner.

> 3. XML output bloated when names used as tags.

This one made me laugh out loud! Do Hummer owners worry about the weight of the smashed bugs on the windshield decreasing their fuel economy?

> 4. Bloats data packet size when result set sent to client.

Irrelevant. Modern networks send big packets very fast. What will kill you is if you try to send lots of packets; big or small, doesn't matter.

> 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!

The overriding concern should be with maintainability and clarity. Choose names that help rather than hinder, and if they are long, so be it.

-- 
Roy