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
  #111  
Old   
Bob Badour
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:34 PM






Gints Plivna wrote:

Quote:
On 5 Dec., 21:07, Ed Prochak <edproc... (AT) gmail (DOT) com> wrote:

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

Several years ago I was more categoric about these things, today I'd
say that wahtever suits one better is OK, however I personally stick
to surrogates for new apps anyway
That's a non-answer if I ever heard one. The design criteria for primary
keys are uniqueness, irreducibility, familiarity, stability and
simplicity -- not necessarily in that order. The criteria frequently
contradict one another requiring the designer to make tradeoffs.

Your attitude basically says you don't have a clue how to do real design
so you use a simplistic rule instead. Evaluating designs and
understanding design tradeoffs is central to what we do.


Reply With Quote
  #112  
Old   
Bob Badour
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:34 PM






Gints Plivna wrote:

Quote:
On 5 Dec., 21:07, Ed Prochak <edproc... (AT) gmail (DOT) com> wrote:

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

Several years ago I was more categoric about these things, today I'd
say that wahtever suits one better is OK, however I personally stick
to surrogates for new apps anyway
That's a non-answer if I ever heard one. The design criteria for primary
keys are uniqueness, irreducibility, familiarity, stability and
simplicity -- not necessarily in that order. The criteria frequently
contradict one another requiring the designer to make tradeoffs.

Your attitude basically says you don't have a clue how to do real design
so you use a simplistic rule instead. Evaluating designs and
understanding design tradeoffs is central to what we do.


Reply With Quote
  #113  
Old   
Bob Badour
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:34 PM



Gints Plivna wrote:

Quote:
On 5 Dec., 21:07, Ed Prochak <edproc... (AT) gmail (DOT) com> wrote:

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

Several years ago I was more categoric about these things, today I'd
say that wahtever suits one better is OK, however I personally stick
to surrogates for new apps anyway
That's a non-answer if I ever heard one. The design criteria for primary
keys are uniqueness, irreducibility, familiarity, stability and
simplicity -- not necessarily in that order. The criteria frequently
contradict one another requiring the designer to make tradeoffs.

Your attitude basically says you don't have a clue how to do real design
so you use a simplistic rule instead. Evaluating designs and
understanding design tradeoffs is central to what we do.


Reply With Quote
  #114  
Old   
Bob Badour
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:34 PM



Gints Plivna wrote:

Quote:
On 5 Dec., 21:07, Ed Prochak <edproc... (AT) gmail (DOT) com> wrote:

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

Several years ago I was more categoric about these things, today I'd
say that wahtever suits one better is OK, however I personally stick
to surrogates for new apps anyway
That's a non-answer if I ever heard one. The design criteria for primary
keys are uniqueness, irreducibility, familiarity, stability and
simplicity -- not necessarily in that order. The criteria frequently
contradict one another requiring the designer to make tradeoffs.

Your attitude basically says you don't have a clue how to do real design
so you use a simplistic rule instead. Evaluating designs and
understanding design tradeoffs is central to what we do.


Reply With Quote
  #115  
Old   
Bob Badour
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:34 PM



Gints Plivna wrote:

Quote:
On 5 Dec., 21:07, Ed Prochak <edproc... (AT) gmail (DOT) com> wrote:

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

Several years ago I was more categoric about these things, today I'd
say that wahtever suits one better is OK, however I personally stick
to surrogates for new apps anyway
That's a non-answer if I ever heard one. The design criteria for primary
keys are uniqueness, irreducibility, familiarity, stability and
simplicity -- not necessarily in that order. The criteria frequently
contradict one another requiring the designer to make tradeoffs.

Your attitude basically says you don't have a clue how to do real design
so you use a simplistic rule instead. Evaluating designs and
understanding design tradeoffs is central to what we do.


Reply With Quote
  #116  
Old   
Bob Badour
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:34 PM



Gints Plivna wrote:

Quote:
On 5 Dec., 21:07, Ed Prochak <edproc... (AT) gmail (DOT) com> wrote:

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

Several years ago I was more categoric about these things, today I'd
say that wahtever suits one better is OK, however I personally stick
to surrogates for new apps anyway
That's a non-answer if I ever heard one. The design criteria for primary
keys are uniqueness, irreducibility, familiarity, stability and
simplicity -- not necessarily in that order. The criteria frequently
contradict one another requiring the designer to make tradeoffs.

Your attitude basically says you don't have a clue how to do real design
so you use a simplistic rule instead. Evaluating designs and
understanding design tradeoffs is central to what we do.


Reply With Quote
  #117  
Old   
Bob Badour
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:34 PM



Gints Plivna wrote:

Quote:
On 5 Dec., 21:07, Ed Prochak <edproc... (AT) gmail (DOT) com> wrote:

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

Several years ago I was more categoric about these things, today I'd
say that wahtever suits one better is OK, however I personally stick
to surrogates for new apps anyway
That's a non-answer if I ever heard one. The design criteria for primary
keys are uniqueness, irreducibility, familiarity, stability and
simplicity -- not necessarily in that order. The criteria frequently
contradict one another requiring the designer to make tradeoffs.

Your attitude basically says you don't have a clue how to do real design
so you use a simplistic rule instead. Evaluating designs and
understanding design tradeoffs is central to what we do.


Reply With Quote
  #118  
Old   
Bob Badour
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:34 PM



Gints Plivna wrote:

Quote:
On 5 Dec., 21:07, Ed Prochak <edproc... (AT) gmail (DOT) com> wrote:

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

Several years ago I was more categoric about these things, today I'd
say that wahtever suits one better is OK, however I personally stick
to surrogates for new apps anyway
That's a non-answer if I ever heard one. The design criteria for primary
keys are uniqueness, irreducibility, familiarity, stability and
simplicity -- not necessarily in that order. The criteria frequently
contradict one another requiring the designer to make tradeoffs.

Your attitude basically says you don't have a clue how to do real design
so you use a simplistic rule instead. Evaluating designs and
understanding design tradeoffs is central to what we do.


Reply With Quote
  #119  
Old   
DBMS_Plumber
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:40 PM




SELECT
Opinions_We_Will_All_Come_To_Regret.Incoherent_Bla thering_Studded_With_Meaningless_Buzzwords_And_Sal ted_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_Ar ise_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_Ar ise_And_Eat_The_Brains_Of_The_Living.Term_Original ly_Stolen_From_A_Distantly_Related_Discipline
IN
Opinions_We_Will_All_Come_To_Regret.The_List_Of_Th ings_Last_Weeks_Trade_Journals_Seemed_To_Be_Intere sted_In;


Reply With Quote
  #120  
Old   
DBMS_Plumber
 
Posts: n/a

Default Re: Long column names...Performance issues? - 12-05-2008 , 03:40 PM




SELECT
Opinions_We_Will_All_Come_To_Regret.Incoherent_Bla thering_Studded_With_Meaningless_Buzzwords_And_Sal ted_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_Ar ise_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_Ar ise_And_Eat_The_Brains_Of_The_Living.Term_Original ly_Stolen_From_A_Distantly_Related_Discipline
IN
Opinions_We_Will_All_Come_To_Regret.The_List_Of_Th ings_Last_Weeks_Trade_Journals_Seemed_To_Be_Intere sted_In;


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 - 2013, Jelsoft Enterprises Ltd.