Surrogate key or multi-column natural key - performance question ...
From: Joergen Bech (jbech_at_post1.tele.dk)
Date: 12/07/04
- Next message: Li Pang: "RE: How to improve the performance"
- Previous message: Jim Slade: "Re: Using Variable In Place of Table Name in SQL Statements (in Sproc)"
- Next in thread: Joergen Bech: "Re: Surrogate key or multi-column natural key - performance question ..."
- Reply: Joergen Bech: "Re: Surrogate key or multi-column natural key - performance question ..."
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 07 Dec 2004 10:44:19 +0100
Don't want to open the big can of worms called
"surrogate vs. natural keys". Please, no flames :)
Question is: Suppose I have master/detail tables
with the master tables having 3-to-5 column natural
primary keys. Suppose those columns were fairly short, i.e.
10-20 bytes total. Would it make sense to add surrogate
keys (uniqueidentifier - not 4-byte identifier ones) and
use those as primary keys instead? For detail lookups,
this, I think, would simplify coding a great deal, but what
about performance? Is it just as fast using multi-column
natural keys than uniqueidentifier surrogate keys, provided
the total length is less than (or at least not much greater than)
that of a uniqueidentifier column? Or is there a significant
cost associated with using multiple columns?
Anyone who have done some real-life tests on this subject?
TIA,
JB
- Next message: Li Pang: "RE: How to improve the performance"
- Previous message: Jim Slade: "Re: Using Variable In Place of Table Name in SQL Statements (in Sproc)"
- Next in thread: Joergen Bech: "Re: Surrogate key or multi-column natural key - performance question ..."
- Reply: Joergen Bech: "Re: Surrogate key or multi-column natural key - performance question ..."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|