Re: Does it make sense to have 2 unique keys in one table?

In article <nigel.stanger-1010951714250001@ou176027.otago.ac.nz>, nigel.stanger@stonebow.otago.ac.nz (Nigel Stanger) wrote: > This is a common misconception, i.e., that "unique key" = "primary key". > They're actually two different things. Any given table can have several > unique keys, but it can only have one _primary_ key. For example, an > employee might have an employee number and a social security number, both > of which are unique keys (known in relational theory as _candidate keys_). > Which one you use as the primary key is a matter of choice. You have fallen prey to yet another common misconception - at least one that is true for Canada and likely most other places who have SSN, or as we call them, Social Insurance Numbers - SINs (we'll leave out all the jokes for now). The ideas are that everyone has one and only one, and hence they make good keys. Based on extensive analysis by a colleague, not everyone gets one, some people get more than one, and more than one person will have the same number. These latter are known as mistakes and shouldn't happen, but being the real world, they do. When I teach keys, I cover - key - determines another value superkey - determines all values in a single row candidate key - a minimal superkey (which the original example violated) primary key - the chosen candidate key foreign key - a primary key value residing in another table -- Douglas Holmes umholme0@ccu.umanitoba.ca