Talk:Surrogate key

message: Some Anonymous Hero's decided that it's better to throw out everybody else's work and dump in some essay they wrote themselves. I'm marking this for wikification, and I'm going to wikify and merge in some of the old content if it's relevant when I've more time. --Kgaughan 19:35, 13 December 2005 (UTC)
thread_title:  Hrmph! 

message: This article needs attention. The current posting is correct, though quite poorly written. It's certainly relational-centric.
The old article seems to confuse system-assigned keys with surrogate keys, particularly in this paragraph: ""Surrogate key" may also be known as "System-generated key", "Database Sequence number", "Synthetic key", "Technical key" or an "Arbitrary, unique identifier"."
I don't think either version thinks of "surrogate keys" from the point of view of data warehousing, though.
-- 03:01, 31 December 2005 (UTC)
replies: text: Huh?  Surrogate Keys are, AFAIK, a relational database concept.  How does the term even apply to other kinds of databases? Jberkus 19:05, 23 September 2006 (UTC)
thread_title:  Needs Attention 

message: Surely a surrogate key and a primary key are identical? 
Is there really any difference?
:Sure there is. A primary key can be surrogate, or it can be natural. A surrogate key is always a candidate key, but may or may not be designated primary key (as any other candidate key, really). Of course, in practice surrogate keys are pretty much always primary keys (but not vice versa, though surrogate primary keys seem to be more popular at the moment). -- int19h 08:12, 11 September 2006 (UTC)
thread_title:  Similarities 

message: I've added a summary of the main advantages and disadvantages of Surrogate Keys.  I've also linked my own blog article; I realize that linking one's on blog is in poor taste, so if someone else has an article which extensively catalogs the disadvantages of surrogate keys, then please link it instead.   Jberkus 19:07, 23 September 2006 (UTC)
thread_title:  Added Advantages/Disadvantages 

message: Isn't surrogate keys more applied in the data warehousing for relating fact and dimension tables. Surrogate keys are also one of the solution for the "Slowly Changing Dimension" problem. I strongly feel this has to be included along with the following external link . —The preceding unsigned comment was added by 203.123.182.27 (talk) 05:19, 2 February 2007 (UTC)
thread_title:  Surrogate Keys in Data Warehouse 

message: "several database application development systems, drivers, and object-relational mapping systems, such as Ruby on Rails or Hibernate, depend on the use of integer or GUID surrogate keys in order to support database-system-agnostic operation and object-to-row mapping."
Hibernate works fine with non-surrogate key, even with composite keys, see . I know little about Ruby on Rails, but I very much doubt that they require surrogate keys.
:—The preceding unsigned comment was added by 85.158.137.195 (talk) 11:16, 20 April 2007 . (sig added by --FvdP (talk) 16:07, 9 May 2008 (UTC)
thread_title:  Compatibility 

message: "However, a randomly generated primary key must be queried before assigned to prevent duplication and cause an insert rejection."
Really ? Isn't the point of some random generation schemes (random 128-bit UUIDs) to make the test redundant by making the collision probability definitely negligible ? Also can't the collision, if need be, be checked after rejection by the uniqueness constraint ? --FvdP (talk) 16:12, 9 May 2008 (UTC)
thread_title:  Random keys 

message: The following subsection was added to the Disadvantages section:
"For some queries, the existence of a surrogate key may result in the need for more |joins in order to retrieve the needed information. E.g., if a table of telephone numbers uses a surrogate key (some counter) instead of the natural key (the telephone number), referencing tables need to be joined with the telephone number table, in order to retrieve actual telephone numbers." I moved it here because it needs some more thought. This disadvantage is not a surrogate/natural key choice; instead, it is an over-normalization. See Database normalization. Timhowardriley (talk) 22:05, 26 January 2009 (UTC)
replies: text: The telephone number table doesn't have to have only one column (I assume that this is what you were thinking when you wrote "over-normalization"?) The example could certainly be better. But when using surrogate keys, child tables don't include data from referred parent tables, meaning that a join is needed when you need data from the natural key based on rows on the child table; because of this, there are cases where you save a join when using natural keys. TroelsArvin (talk) 22:49, 26 January 2009 (UTC)
replies: text: Regarding "The example could certainly be better.": I agree. However, I disagree that performance in this context is significantly effected; it's only marginally effected. Performance would only be marginally effected by joins of natural keys because of the increased size of the natural key over that of a surrogate key. Timhowardriley (talk) 17:20, 27 January 2009 (UTC)
replies: text: So let's agree on the fact that extra joins may result from using surrogate keys, right? That can - all else being equal - only be a drawback of surrogate keys. Is it significant? - In the hot new column store databases, it may not be so significant. In traditional row-store databases, an extra join can certainly be significant. I assert that it's rather uncontroversial to try to eliminate extra joins.TroelsArvin (talk) 21:47, 27 January 2009 (UTC)
thread_title:  New disadvantage: "Performance" 

message: I ought to have read the discussion page before making edits, but I didn't. I also out to have logged on first - the edits are under ip address 124.178.225.104 . I have made a few changes where I thought the wording was a trifle clumsy, although I have tries to keep what I think the intended meaning was ("dissassociated" isn't a very good word, but I now what you mean).
I've also added a bit here and there.
The stuff on the caveats relating to randomly generated keys needs to be moved out, as it is duplicated.  —Preceding unsigned comment added by Paul Murray (talk • contribs) 11:13, 26 March 2009 (UTC)
replies: text: Your additions are surely productive. The duplication should remain to keep each paragraph independent. Timhowardriley (talk) 05:27, 27 March 2009 (UTC)
thread_title:  Altered a few of the sections 

message: I removed this text. "Although applications accessing the database should be free of bugs and never attempt to create rows with duplicate natural keys, nevertheless properly maintained unique keys are a vital "last line of defense" against this type of data corruption. This is particularly the case where data is sometimes mutated by user-entered SQL. Of course, due to the very fact that a well-tested and bedded down application will not attempt to introduce duplicate keys, the absence of database constraints is often not immediately apparent as a problem.
Modern databases, however, can apply database triggers to enforce unique constraints." It's meaning should be more clear. I'm not sure if it refutes or supports the previous sentence that says, "Without a unique index on the natural key, duplicate rows can appear and once present can be difficult to identify." Timhowardriley (talk) 19:16, 13 May 2011 (UTC)
thread_title:  Removed Disadvantages/Normalization paragraph 

message: The example given in the Requirements changes section is not an argument for Oracle sequences or similar approaches, because those sequences would have been independent in the two separate companies as well (unless they used a shared database such as a clouid-hosted seevice). However, it seems like a good example for why to use UUIDs. Any objections to noting this?--greenrd (talk) 09:36, 2 February 2012 (UTC)
thread_title:  Requirements changes 

message: Is Definition (1)  from P. Hall, J. Owlett, S. Todd, ``Relations and Entities, in ``Modeling in Data Base Management Systems, G.M. Nijssen (ed.), pp 201-220, North-Holland, 1976?  — Preceding unsigned comment added by 91.37.175.230 (talk) 08:04, 25 October 2012 (UTC)
thread_title:  References