Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234

Surogate Keys are not always the answer but are freqently used Expand / Collapse
Author
Message
Posted Thursday, October 14, 2010 3:06 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 1:11 PM
Points: 3,081, Visits: 11,230
Always use Surrogate keys for the primary key. Add unique constraints on all natural keys (alternate keys).

Any other approach will eventually get you in trouble.
Post #1004811
Posted Thursday, October 14, 2010 4:16 PM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Yesterday @ 8:03 AM
Points: 4,052, Visits: 4,192
So you are suggesting that you should never consider a Natural or Candidate Key as the primary and always use a surrogate key regardless of the circumstances?

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Post #1004834
Posted Friday, October 15, 2010 1:53 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, September 02, 2013 5:45 AM
Points: 112, Visits: 296
I know Michael from another forum and have the greatest of respect for him, but I will respectfully disagree. The requirements of some systems necessarily require natural keys, for others they are preferable to surrogates.
Post #1004945
Posted Friday, October 15, 2010 2:01 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Today @ 12:51 AM
Points: 429, Visits: 3,083
Michael Valentine Jones (10/14/2010)
Always use Surrogate keys for the primary key. Add unique constraints on all natural keys (alternate keys).


A primary key means exactly the same thing as an alternate key so as you've written it this advice doesn't make much sense. I expect you mean "avoid using business data in any foreign key references" but that's different. Anyway, using natural keys for foreign key references can be very useful, advantageous and sometimes necessary.



David
Post #1004953
Posted Friday, October 15, 2010 4:01 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 7:10 PM
Points: 8,280, Visits: 8,727
Michael Valentine Jones (10/14/2010)
Always use Surrogate keys for the primary key. Add unique constraints on all natural keys (alternate keys).

Any other approach will eventually get you in trouble.


Do you really believe that or are you just trolling?


Tom
Post #1005004
Posted Friday, October 15, 2010 12:24 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 1:11 PM
Points: 3,081, Visits: 11,230
Tom.Thomson (10/15/2010)
Michael Valentine Jones (10/14/2010)
Always use Surrogate keys for the primary key. Add unique constraints on all natural keys (alternate keys).

Any other approach will eventually get you in trouble.


Do you really believe that or are you just trolling?



Of course I believe what I say.

I didn’t want to get into a big debate because it never changes anyone’s mind, but I just thought this thread needed to have a counterpoint to what seemed to be a “use natural keys” lovefest so that new people are aware that is not a universal sentiment, and that the always use surrogate keys position is a valid approach.

To briefly state my position:
I always use surrogate primary keys for the simple reason that I have never had reason to regret that, but have regretted the use of natural keys (usually be other people) on many, many occasions when those natural keys turned out to be not so immutable or to even be unique.



Post #1005470
Posted Friday, October 15, 2010 12:33 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 1:11 PM
Points: 3,081, Visits: 11,230
David Portas (10/15/2010)
Michael Valentine Jones (10/14/2010)
Always use Surrogate keys for the primary key. Add unique constraints on all natural keys (alternate keys).


A primary key means exactly the same thing as an alternate key so as you've written it this advice doesn't make much sense. I expect you mean "avoid using business data in any foreign key references" but that's different. Anyway, using natural keys for foreign key references can be very useful, advantageous and sometimes necessary.



That seems like a bit of nit picking. I think it's obvious in the context that what I meant is to make the surrogate key the primary key constraint and to put unique constraints on the remaining keys.

I do have to disagree with the statement that "using natural keys for foreign key references can be very useful, advantageous and sometimes necessary", especially the necessary part.



Post #1005485
Posted Friday, October 15, 2010 6:19 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Today @ 12:51 AM
Points: 429, Visits: 3,083
Michael Valentine Jones (10/15/2010)
David Portas (10/15/2010)
Michael Valentine Jones (10/14/2010)
Always use Surrogate keys for the primary key. Add unique constraints on all natural keys (alternate keys).


A primary key means exactly the same thing as an alternate key so as you've written it this advice doesn't make much sense. I expect you mean "avoid using business data in any foreign key references" but that's different. Anyway, using natural keys for foreign key references can be very useful, advantageous and sometimes necessary.



That seems like a bit of nit picking. I think it's obvious in the context that what I meant is to make the surrogate key the primary key constraint and to put unique constraints on the remaining keys.


In light of your later comments I think it's far from obvious what you mean. You say:

I have regretted the use of natural keys (usually be other people) on many, many occasions when those natural keys turned out to be not so immutable or to even be unique.


But if a "key" is not unique then it isn't suitable as a natural key whether referenced by a foreign key or not! So how can you say that you are in favour of such natural keys but opposed to their use as foreign keys? Similarly for immutability - especially since immutability of keys is anyway an illusion or at least a rather arbitrary point of view. What matters is not whether key values can change but whether they accurately identify the things they are supposed to identify.


David
Post #1005649
Posted Saturday, October 16, 2010 8:23 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 7:10 PM
Points: 8,280, Visits: 8,727
Michael Valentine Jones (10/15/2010)
Tom.Thomson (10/15/2010)
Michael Valentine Jones (10/14/2010)
Always use Surrogate keys for the primary key. Add unique constraints on all natural keys (alternate keys).

Any other approach will eventually get you in trouble.


Do you really believe that or are you just trolling?



Of course I believe what I say.


I'm somewhat surprised, because it seems a very extreme position. It makes exactly as much sense to me as saying "always use natural keys" (ie none at all).

I didn’t want to get into a big debate because it never changes anyone’s mind, but I just thought this thread needed to have a counterpoint to what seemed to be a “use natural keys” lovefest so that new people are aware that is not a universal sentiment, and that the always use surrogate keys position is a valid approach.

To briefly state my position:
I always use surrogate primary keys for the simple reason that I have never had reason to regret that, but have regretted the use of natural keys (usually be other people) on many, many occasions when those natural keys turned out to be not so immutable or to even be unique.


I will stick to my own position, which is to use a surrogate key when it it not sensible to use a natural key, use a natural key when it is not sensible to use a surrogate key, and where each will work use whichever will work better. I've been badly bitten by a design (not mine - I just had to clear up the mess when the system fell in a heap) that used surrogate keys for everything, and equally badly bitten by a design (again not mine, I just ended up doing cleanup) that used natural keys for everything (someone used an 800 byte collection of columns as the clustering key for one table, as well as as a forign key in several tables referncing that one). In my experience it has often been useful to use a natural key than not, but not anything like 100% of the time.


Tom
Post #1005742
« Prev Topic | Next Topic »

Add to briefcase «««1234

Permissions Expand / Collapse