Re: Long column names...Performance issues?

"Gints Plivna" <gints.plivna_at_gmail.com> wrote in message news:1069696d-8855-4ed2-9bce-ae3dfeaaa597_at_j38g2000yqa.googlegroups.com...
> On 19 Nov., 19:29, chenthorn <car..._at_hotmail.com> wrote:
>> I would like to hear from the community what you all feel are best
>> practices regarding naming conventions, and how they affect your
>> environment.
>
> I'd say that naming has (almost) nothing to do with performance of
> code, but it definitely has something to do with performance of coders
> producing the code. Even with gui tools suggesting variants and
> helping people not so familiar with schema it is hard to write
> ThisLongAndWindyVariableNameExactlyDescribingWhatIsItsMainGoalAndExplainingWhyItWasCreatedAsWellAsAddingSomeOtherInfo.
> On the other hand writing just i, j, k, l, m, n is also very dangerous
> because it is hard to understand why these were creted, for what used
> etc etc.
> So the problem of course is to find where the golden mean lies.

I think you're onto something with the "golden mean". I think the term "decriptive" might be replaced by the term "mnemonic". The purpose isn't so much to describe the table or column via its name, but rather to allow the name to trigger an association for the human reader (presumably a programmer) who has previously been exposed to a description.

In assembly language, the opcode "103" carries almost no mnemonic value at all. The symbolic opcode "a" might carry a little mnemonic value. The opcode "add" carries a lot more. In this case, the time needed to type the extra two letters without error is trivial compared to the chance of mistyping the opcode "a" instead of the opcode "s", or the time needed to remember that "a" stands for addition and not appending. In terms of column names, "ID" carries almost no mnemonic value. "EmpID" carries a little more, and "EmployeeID" carries even more than that.

One quibble: validating the longer table and column names, and filling in long names based on fewer keystrokes, requires access to a copy of the metadata stored in the database data dictionary. A compiler cannot check these names the same way it checks program variable names.

Another point: most of us resort to very abbreviated names for table aliases and column aliases. The lexical scope of these aliases is so small that making them mnemonic would hardly be worth the effort.

You are right about the performance issues being next to nothing. Especially if the long names are parsed and bound prior to execution. Received on Fri Nov 21 2008 - 20:50:06 CET