Long column names...Performance issues?

#41

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!

#42

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!

#43

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!

#44

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!

#45

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!

#46

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!

#47

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!

#48

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!

#49

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!

#50

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!