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

Default Re: Long column names...Performance issues? - 11-19-2008 , 05:57 PM






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

Quote:
Thanks in advance!




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

Default Re: Long column names...Performance issues? - 11-19-2008 , 05:57 PM






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

Quote:
Thanks in advance!


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

Default Re: Long column names...Performance issues? - 11-19-2008 , 05:57 PM



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

Quote:
Thanks in advance!


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

Default Re: Long column names...Performance issues? - 11-19-2008 , 05:57 PM



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

Quote:
Thanks in advance!


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

Default Re: Long column names...Performance issues? - 11-19-2008 , 05:57 PM



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

Quote:
Thanks in advance!


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

Default Re: Long column names...Performance issues? - 11-19-2008 , 05:57 PM



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

Quote:
Thanks in advance!


Reply With Quote
  #47  
Old   
chenthorn
 
Posts: n/a

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



On Nov 19, 3:57*pm, toby <t... (AT) telegraphics (DOT) com.au> wrote:
Quote:
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).
3. XML output bloated when names used as tags.
4. Bloats data packet size when result set sent to client.

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
  #48  
Old   
chenthorn
 
Posts: n/a

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



On Nov 19, 3:57*pm, toby <t... (AT) telegraphics (DOT) com.au> wrote:
Quote:
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).
3. XML output bloated when names used as tags.
4. Bloats data packet size when result set sent to client.

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
  #49  
Old   
chenthorn
 
Posts: n/a

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



On Nov 19, 3:57*pm, toby <t... (AT) telegraphics (DOT) com.au> wrote:
Quote:
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).
3. XML output bloated when names used as tags.
4. Bloats data packet size when result set sent to client.

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
  #50  
Old   
chenthorn
 
Posts: n/a

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






On Nov 19, 3:57*pm, toby <t... (AT) telegraphics (DOT) com.au> wrote:
Quote:
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).
3. XML output bloated when names used as tags.
4. Bloats data packet size when result set sent to client.

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