Re: Surrogate Key
From: Tony Rogerson (tonyrogerson_at_sqlserver.eu.com)
Date: 01/06/05
- Next message: Adam Machanic: "Re: alter tables add 365 columns"
- Previous message: Murat BUDAK: "Continuous varchar data"
- In reply to: Anith Sen: "Re: Surrogate Key"
- Next in thread: Anith Sen: "Re: Surrogate Key"
- Reply: Anith Sen: "Re: Surrogate Key"
- Reply: --CELKO--: "Re: Surrogate Key"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 6 Jan 2005 15:52:53 -0000
>>>>Being applicable at the logical level, surrogate keys have nothing by
>>>>themselves associated with performance, contrary to popular perception.
Mmmmm - i beg to differ Anith.
I use the good old IDENTITY property on columns definied as int for my
surrogate (artificial) keys and then use those id's in drop downs and keys
within the application outside the database pure and simply for performance
and easy of use, composite keys are painful and not really practical when
used as the value property on the listbox object for instance.
I think the biggest mistake people make is not treating the database as part
of the application, it is quite often treat as seperate entity.
More scalable, more matainable and quicker developed applications can be
built if application and database work together.
Draw backs of using primary keys are varied, two of the most important in my
mind is that changing the primary key is very difficult without using a
surrogate and the second is what i've mentioned about re: performance and
use of composite keys.
Should start a good debate ;)
-- Tony Rogerson SQL Server MVP http://www.sqlserverfaq.com?mbr=21 (Create your own groups, Forum, FAQ's and a ton more)
- Next message: Adam Machanic: "Re: alter tables add 365 columns"
- Previous message: Murat BUDAK: "Continuous varchar data"
- In reply to: Anith Sen: "Re: Surrogate Key"
- Next in thread: Anith Sen: "Re: Surrogate Key"
- Reply: Anith Sen: "Re: Surrogate Key"
- Reply: --CELKO--: "Re: Surrogate Key"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|