Talk:Unique key

message: Unique with respect to DBMS is a value which is unique. Unique key is like a primary key but unique key may start from "0".
:Such semantics (=0) are by no means implied by unique keys. --Stolze 14:48, 14 February 2007 (UTC)
replies: text: Which is why a column with a unique key will only allow one row where the value of the column is null. Jerazol 14:47, 27 July 2007 (UTC)
thread_title: Remark

message: Editors,
This article, "Unique Key", is redundant with Candidate Key, Primary Key and Superkey.  It has no reason to exist.  Please delete it. Jberkus 20:04, 23 September 2006 (UTC)
replies: text: Take it to WP:AFD if you feel that strongly about it. --Spartaz 21:47, 23 September 2006 (UTC)

text: I copied the contect from the PK article here because it logically belongs here (PK is just a special unique key).  Unless there are some objects, I will make primary key a redirect to this article here. --Stolze 14:48, 14 February 2007 (UTC)
thread_title:  Please delete this article -- it's redundant 

message: I got redirected from "Primary key". This doesn't make sense to me. Because that's not the same. A primary key necessarily is an unique key but a unique key must not be a primary key. Is this correct or am i wrong?
--Florian Sening 09:43, 30 July 2007 (UTC)
replies: text: A primary key is essentially a unique key, with a NOT NULL constraint added. It seems redundant to maintain 2 separate articles for 2 concepts as similar as these. Jerazol 10:23, 30 July 2007 (UTC)
thread_title:  Difference: unique key vs. primary key 

message: [...]surrogate primary keys as an inalienable part of the relational data model.
This is sooo wrong. Surrogate keys are by no means a part of the relational data model. They are just there because relational databases are abused to store data from an object-oriented world where everybody is thinking in objects. If you use relational databases like they are meant to be used (for predicate logic) then most of the time there is no need for surrogate keys.
Don't get me wrong - i don't favor natural keys over surrogate keys or vice versa, but this passage is just wrong. You get the feeling that surrogate keys are the way to "do it" but it doesn't even explain why they exist. I mean - it's not that this is the only reason to use surrogate keys - but this sentence just gives the wrong clue.
What do others think about that?
--Florian Sening 09:57, 30 July 2007 (UTC)
replies: text: Did you read the complete passage? Jerazol 10:21, 30 July 2007 (UTC)
thread_title:  Surrogate Keys 

message: Would a primary key be the key that happens to have the clustered index over it? --Damian Yerrick (talk | stalk) 14:08, 2 August 2007 (UTC)
replies: text: Indexes have nothing to do (logically) with constraints.  A DBMS may choose to implement a unique key constraint using an index that checks for uniqueness. --Stolze 19:22, 7 August 2007 (UTC)
thread_title:  Primary keys and clustered indexes? 

message: Primary keys can be the target of foreign key constraints, and as such are part of referential integrity.
--David Garfield (talk) 21:46, 29 January 2008 (UTC)
replies: text: OK, there is a claim that unique keys can be part of a foreign key constraing.  I've never seen that in a database.  I would agree that it is a logical generalization, and have wondered at times why it isn't supported.  --22:21, 29 January 2008 (UTC)
thread_title:  missing difference between Unique and Primary keys. 

message: I am surprised that the article gives the (US) SSN as an example of a unique key, since it violates the fundamental property in two different ways: "a unique key must uniquely identify all possible rows".
For most databases, the SSN cannot identify all possible rows, since the vast majority of individuals do not have an SSN.   (The exceptions are databases that are intended to only ever include individuals who are citizens or residents of the USA.)
Secondly, the SSN is does not uniquely identify even those who have them: millions of Americans have been assigned more than one SSN (usually they are given a replacement because of some problem).  And there are some SSNs that are in use (mistakenly) by multiple individuals.   The result is that there is no unique mapping between SSNs and American citizens/residents.
There is another problem: the widespread use of SSNs as both a personal identifier and for authentication (in the mistaken belief that no-one will know someone else's SSN) makes the number very attractive to identity thieves.  As as result, many Americans will refuse to give their SSN - or if pushed will supply a fake number.   Also, privacy laws in some US states may make it illegal to use SSNs or even to ask for them.
All in all, this makes the SSN a very poor choice for a unique key.   Its inclusion in this article might make people think that SSNs are a good choice for a unique key, and thus lead to the development of yet more databases that use SSNs for this purpose.  This is bad for two reasons: such databases exclude the ~96% of the world's population who do not have an American SSN, and are a privacy and identity theft risk for Americans.
TomH (talk) 23:31, 28 May 2008 (UTC)
replies: text: It says, correctly, the SSN can identify all possible rows, not all possible people. It might be a table of people with SSNs. The point is that it's unique. As for people lying about their SSN, well, if the data is just plain wrong then that's not a database issue. You might as well argue that numbers aren't unique in general because someone might lie and say there are two different numbers called 5. 86.183.163.162 (talk) 18:32, 14 June 2011 (UTC)
thread_title:  SSN 

message: These are related, possibly even overlapping concepts, but their relationship is not discussed either here nor in Superkey.  Any volunteers?  DES (talk) 16:51, 29 September 2008 (UTC)
thread_title:  Primary key vs. Unique key vs. Superkey 

message: Reading the unique key article, I cannot see a significant conceptual difference between it and candidate key and/or superkey.  The definition in the lead seems to say either one, or the other, or (perhaps) a special instance of either. Perhaps there is a confusion between the abstract relational database model and practical implementations of it? I have propsed a merge of "unique key" and "superkey". If that is inappropriate, it seems that further clarification is needed. All the best, --Jorge Stolfi (talk) 02:03, 11 August 2009 (UTC)
thread_title:  Merge proposed with [[superkey]] 

message: The Key field article has no business being a separate article.  It should, at most, be a subsection of this article.  It's currently a stub.  I recommend getting rid of that stub and merging it into this article. 69.116.234.82 (talk) 02:55, 27 March 2010 (UTC)
replies: text: No real discussion on this after 2.5 years, so I've merged this as uncontroversial. WTF? (talk) 23:07, 10 February 2013 (UTC)
thread_title:  Merge proposed with [[Key field]] 

message: Reformatted the information as it was extremely spread out, also found a page about an alternate key page on the Oracle FAQ. I feel it could maybe use some peer improvement though. I'm not satisfied with my text. 62.140.137.122 (talk) 00:05, 18 April 2011 (UTC)
thread_title:  Merged information from Alternate key 

message: Misconception.
The current text (October 8, 2011) states that "a column defined as unique key column allows only one NULL value, which in turn can identify that row/tuple."
This is wrong!
According to the ANSI / ISO SQL and Relational Model theory, NULL should not be considered as a value repetition (since it represents "no value" or "value unknown"). Thus, a "unique constraint" (unique key) should allow more than one row with null.
Some RDBMS do not allow (such as Microsoft SQL Server), but are not in accordance with the standard.
Some others (like Oracle or PostgreSQL) implement in accordance with correct concept.  — Preceding unsigned comment added by 201.81.69.28 (talk) 16:51, 8 October 2011 (UTC)
thread_title:  Misconception: unique and null 

message: This article is extremely unclear and has many inaccuracies. The cause seems to be that at least three quite different topics are included but not properly differentiated: 1) Keys in Entity Relationship Modelling, 2) Keys in the Relational model, 3) UNIQUE and PRIMARY KEY constraints in SQL. For example the statement "the key that is allowed to migrate to other entities to define the relationships" makes some sense in an ER modelling context but is irrelevant to the Relation model. Similarly the statements about nulls in UNIQUE constraints are specific to SQL. Would it be better split into separate pages for "Keys (Relational)" and "Keys (ER)". Optionally, either of those pages could say something about SQL implementation issues. Oradium (talk) 22:33, 13 January 2015 (UTC)
thread_title:  Lacks a single topic. Should be split. 

message: Hello fellow Wikipedians,
I have just modified  on Unique key. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive http://web.archive.org/web/20120425052025/http://www.xcdsql.org/Summary%20of%20SQL.html to http://www.xcdsql.org/Summary%20of%20SQL.html#chapter-Table%20constraints
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 20:05, 20 July 2016 (UTC)
thread_title:  External links modified 

message: The article intro says:
 a unique key (a redundant term since a key, by definition, implies attribute(s) value(s) uniqueness, therefore it should be avoided) is a superkey
This suggests that "key" = "unique key" = "superkey" are all synoyms. But then why is there a separate article Superkey, which doesn't say anything about this?
If there is a difference between the terms, even if it's subtle or context-dependent, can someone please edit both articles to make that clear? --79.227.176.47 (talk) 07:16, 9 October 2017 (UTC)
thread_title:  Key vs Unique key vs Superkey 

message: The page should be renamed as "Key (database)" with Unique key as a redirect. As the text already states, "unique key" is a pleonasm. Throughout there seems to be some confusion with unique constraints, but a constraint is not a key and the set of columns covered by a unique constraint is not necessarily a key. Renaming the article might help avoid that confusion. Renaming it would also make more sense of the fact that we now have a separate article for "Primary key": Key (database) would cover keys generally, with primary key dealing with the "special case" explanations.  — Preceding unsigned comment added by Oradium (talk • contribs) 05:52, 25 July 2018 (UTC)
thread_title:  Rename as Key (database) 

message: The first sentence of Unique key specifically says that it is synonymous with Candidate key:
In database relational modeling and implementation, a unique key (also known as a candidate key) of a relation is a minimal superkey for that relation; that is, a set of attributes such that:
And Candidate key has almost the same first sentence, although strangely it says it's synonymous with "secondary key" (note: Secondary key redirects to Secondary chord, a totally unrelated term):
In the relational model of databases, a candidate key(also known as secondary key) of a relation is a minimal superkey for that relation; that is, a set of attributes such that:
And on top of that the two share identical definitions:
# the relation does not have two distinct tuples (i.e. rows or records in common database language) with the same values for these attributes (which means that the set of attributes is a superkey)
# there is no proper subset of these attributes for which (1) holds (which means that the set is minimal).
So, is there a difference?
* If so, that should be explained in one or both articles, and currently it is not. Candidate key does not mention Unique key, and the only places where Unique key mention Candidate key are to say they are synonymous, or to explain the difference between a Candidate key and a Primary key.
* If not, one of these articles should be merged into the other.
Note: I write some basic SQL professionally, but that is the full extent of my qualifications on this. I'm just trying to use Wikipedia to get a basic grasp of these concepts, but this whole set of articles is really kind of hard to follow as a layperson. Let's fix it!
 — nhinchey (talk) 20:10, 31 October 2018 (UTC)
replies: text:  There is no difference. The title "candidate key" is preferable because "unique key" is a tautology. I suggest merging the two under the name Candidate key or, perhaps better: Key_(database), which currently redirects here. Oradium (talk) 22:10, 2 November 2018 (UTC)
thread_title:  Difference between [[Unique key]] and [[Candidate key]] 

message: This paragraph has so many hyperlinks that to a reader who was unaware of what unique keys are, it would be necessary to spend half an hour perusing concepts like "relation", "attribute", "tuple" , "superkey",etc. in order to understand the definition, when the use of common synonyms (table, column, row, etc.) would suffice without the need for such perusal. I've hence taken the liberty of simplifying the prose by using the common terms instead of the technical E.F.Codd-speak terms.
In response to the previous note, while UNIQUE KEY is indeed a tautology, SQL uses the statements "CREATE Primary Key Constraint" and "Create Unique Constraint", not "Create Candidate Constraint" (or, for that matter, it uses "create table" instead of "create relation") and so, it's probably here to stay.
The 1st sentence falsely stated that "alternate key" and "primary key" were synonyms of unique key. A table can contain multiple unique keys (e.g., a surrogate (machine-generated) key and a multi-column key, but only one of these (typically the surrogate key) serves as the primary key. The multi-column key serves as the basis of a UNIQUE constraint.
Prakash Nadkarni (talk) 02:49, 24 March 2020 (UTC)
replies: text: Your edit is probably an improvement except that I don't see a good reason to exclude the mention of alternate and primary keys. This article certainly encompasses both those things since both are keys (and of course they are unique). This is not an article about SQL syntax but about the concept of keys. There is a separate "primary key" page that forked from this one and pointlessly duplicates some of the same info but since key is the more general and more important term this entry ought to deal with the general case. There is a small inaccuracy in your edit because a key can consist of zero attributes - the phrase "one or more" is not correct.
Oradium (talk) 19:42, 26 March 2020 (UTC)
thread_title:  Simplified and corrected the 1st paragraph, including the two bullets