Talk:Unique key
From Wikipedia, the free encyclopedia
 |
This article is within the scope of WikiProject Databases. |
| ??? | This article has not yet received a rating on the assessment scale. |
| Low | rated as low-importance on the assessment scale |
Contents |
[edit] Remark
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)
As "The values in a unique key columns may ... be NULL"; it is not possible that: "A unique key must uniquely identify all possible rows that exist in a table" because rows that are identified by NULL cannot be uniquely distinguished. 212.136.56.20 12:16, 27 July 2007 (UTC)
- 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)
[edit] Please delete this article -- it's redundant
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)
the primary key page doesn't really explain unique key, if this is removed it would be helpful to move the info there.
- 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)
[edit] Difference: unique key vs. primary key
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)
- 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)
Okay. Then we should kill this redundancy as stated above. Okay?
--Florian Sening 14:41, 31 July 2007 (UTC)
[edit] Surrogate Keys
[...]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)
- Did you read the complete passage? Jerazol 10:21, 30 July 2007 (UTC)
You mean the part about "Object-Oriented Programming"? Please be more precise. I sure have read it but that doesn't change the fact that this statement is just plain wrong.
--Florian Sening 14:42, 31 July 2007 (UTC)
[edit] Primary keys and clustered indexes?
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)
- 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)
[edit] missing difference between Unique and Primary keys.
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)
- 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) —Preceding unsigned comment added by Divad27182 (talk • contribs)
[edit] SSN
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.
