Long column names...Performance issues?

#71

chenthorn wrote:

Quote:

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]

Quote:

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.

Quote:

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?

Quote:

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.

Quote:

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

#72

chenthorn wrote:

Quote:

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]

Quote:

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.

Quote:

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?

Quote:

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.

Quote:

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

#73

chenthorn wrote:

Quote:

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]

Quote:

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.

Quote:

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?

Quote:

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.

Quote:

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

#74

Quote: