dbTalk Databases Forums  

Long column names...Performance issues?

comp.databases.theory comp.databases.theory


Discuss Long column names...Performance issues? in the comp.databases.theory forum.

Reply
 
Thread Tools Display Modes
  #71  
Old   
Roy Hann
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-20-2008 , 03:46 PM






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






Reply With Quote
  #72  
Old   
Roy Hann
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-20-2008 , 03:46 PM






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




Reply With Quote
  #73  
Old   
Roy Hann
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-20-2008 , 03:46 PM



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




Reply With Quote
  #74  
Old   
-CELKO-
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-21-2008 , 07:29 AM



Quote:
I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment.
Get a few copies of SQL PROGRAMMING STYLE and use it to set shop
standards. It is based on the ISO-11179 rules and research that we
did decades ago on code readability. It also has the advantage of
being an outside source so you can avoid internal fights -- blame
Celko instead of each other .


Reply With Quote
  #75  
Old   
-CELKO-
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-21-2008 , 07:29 AM



Quote:
I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment.
Get a few copies of SQL PROGRAMMING STYLE and use it to set shop
standards. It is based on the ISO-11179 rules and research that we
did decades ago on code readability. It also has the advantage of
being an outside source so you can avoid internal fights -- blame
Celko instead of each other .


Reply With Quote
  #76  
Old   
-CELKO-
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-21-2008 , 07:29 AM



Quote:
I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment.
Get a few copies of SQL PROGRAMMING STYLE and use it to set shop
standards. It is based on the ISO-11179 rules and research that we
did decades ago on code readability. It also has the advantage of
being an outside source so you can avoid internal fights -- blame
Celko instead of each other .


Reply With Quote
  #77  
Old   
-CELKO-
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-21-2008 , 07:29 AM



Quote:
I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment.
Get a few copies of SQL PROGRAMMING STYLE and use it to set shop
standards. It is based on the ISO-11179 rules and research that we
did decades ago on code readability. It also has the advantage of
being an outside source so you can avoid internal fights -- blame
Celko instead of each other .


Reply With Quote
  #78  
Old   
-CELKO-
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-21-2008 , 07:29 AM



Quote:
I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment.
Get a few copies of SQL PROGRAMMING STYLE and use it to set shop
standards. It is based on the ISO-11179 rules and research that we
did decades ago on code readability. It also has the advantage of
being an outside source so you can avoid internal fights -- blame
Celko instead of each other .


Reply With Quote
  #79  
Old   
-CELKO-
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-21-2008 , 07:29 AM



Quote:
I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment.
Get a few copies of SQL PROGRAMMING STYLE and use it to set shop
standards. It is based on the ISO-11179 rules and research that we
did decades ago on code readability. It also has the advantage of
being an outside source so you can avoid internal fights -- blame
Celko instead of each other .


Reply With Quote
  #80  
Old   
-CELKO-
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-21-2008 , 07:29 AM






Quote:
I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment.
Get a few copies of SQL PROGRAMMING STYLE and use it to set shop
standards. It is based on the ISO-11179 rules and research that we
did decades ago on code readability. It also has the advantage of
being an outside source so you can avoid internal fights -- blame
Celko instead of each other .


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.