On 19 Nov., 21:26, patrick...@yahoo.com wrote:

He was somehow limited in his imagination. I think the very first
technique offered here http://www.web-hits.org/txt/codingunmaintainable.html
(New Uses For Names For Baby) is much better.

Gints Plivna
http://www.gplivna.eu

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.

[]

You had me until the suggestion that all tables should have surrogate
ID primary Keys. Otherwise I think your suggestions look good.

 Ed

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!

SELECT
Opinions_We_Will_All_Come_To_Regret.Incoherent_Blathering_Studded_With_Meaningless_Buzzwords_And_Salted_with_Enough_Jargon_To_Make_You_Feel_Inadequate

 FROM Morons_Paid_Too_Much_By_Clueless_People,
           Opinions_We_Will_All_Come_To_Regret,
Ideas_Which_Are_Dead_But_Manage_Like_Zombies_To_Arise_And_Eat_The_Brains_Of_The_Living
WHERE
Morons_Paid_Too_Much_By_Clueless_People.Name_Used_For_Publicity_Purposes
=
Opinions_We_Will_All_Come_To_Regret.Name_Supplied_By_Admin_Assistant_When_A_Speaking_Slot_Openned_Up
    AND
Ideas_Which_Are_Dead_But_Manage_Like_Zombies_To_Arise_And_Eat_The_Brains_Of_The_Living.Term_Originally_Stolen_From_A_Distantly_Related_Discipline
IN
Opinions_We_Will_All_Come_To_Regret.The_List_Of_Things_Last_Weeks_Trade_Journals_Seemed_To_Be_Interested_In;