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
  #61  
Old   
toby
 
Posts: n/a

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






On Nov 20, 12:29 pm, chenthorn <car... (AT) hotmail (DOT) com> wrote:
Quote:
On Nov 19, 3:57 pm, toby <t... (AT) telegraphics (DOT) com.au> wrote:



On Nov 19, 12:29 pm, chenthorn <car... (AT) hotmail (DOT) 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.

Quote:
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 micro-
optimisation is already costing you money and time!

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!




Reply With Quote
  #62  
Old   
toby
 
Posts: n/a

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






On Nov 20, 12:29 pm, chenthorn <car... (AT) hotmail (DOT) com> wrote:
Quote:
On Nov 19, 3:57 pm, toby <t... (AT) telegraphics (DOT) com.au> wrote:



On Nov 19, 12:29 pm, chenthorn <car... (AT) hotmail (DOT) 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.

Quote:
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 micro-
optimisation is already costing you money and time!

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!


Reply With Quote
  #63  
Old   
toby
 
Posts: n/a

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



On Nov 20, 12:29 pm, chenthorn <car... (AT) hotmail (DOT) com> wrote:
Quote:
On Nov 19, 3:57 pm, toby <t... (AT) telegraphics (DOT) com.au> wrote:



On Nov 19, 12:29 pm, chenthorn <car... (AT) hotmail (DOT) 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.

Quote:
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 micro-
optimisation is already costing you money and time!

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!


Reply With Quote
  #64  
Old   
toby
 
Posts: n/a

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



On Nov 20, 12:29 pm, chenthorn <car... (AT) hotmail (DOT) com> wrote:
Quote:
On Nov 19, 3:57 pm, toby <t... (AT) telegraphics (DOT) com.au> wrote:



On Nov 19, 12:29 pm, chenthorn <car... (AT) hotmail (DOT) 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.

Quote:
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 micro-
optimisation is already costing you money and time!

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!


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

Default Re: Long column names...Performance issues? - 11-20-2008 , 04: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
  #66  
Old   
Roy Hann
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-20-2008 , 04: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
  #67  
Old   
Roy Hann
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-20-2008 , 04: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
  #68  
Old   
Roy Hann
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-20-2008 , 04: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
  #69  
Old   
Roy Hann
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-20-2008 , 04: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
  #70  
Old   
Roy Hann
 
Posts: n/a

Default Re: Long column names...Performance issues? - 11-20-2008 , 04: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
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.