When should a social security number be used as a database primary key?

Question

Our DBA says that because the social security number (SSN) is unique, that we should use it as the primary key in a table.

While I do not agree with the DBA (and hav

Answer 1

Never!

In the USA, both Federally and in the several States, there are strict laws concerning the handling of social security numbers and the uses to which they may be put. As the issue of identity theft comes more-and-more to the forefront, this concern will merely become more-regulated. Therefore, I would strongly recommend that you never use this as a database key. SS# should be a (very confidential) column in the record.

Furthermore, it is a customer-supplied value. Sometimes, the value supplied is incorrect, or missing, or unintentionally duplicated. You should never use customer-supplied values of any sort as a database primary key. You should not use identifiers that are intended "for use by humans" as a database primary key. (Humans tolerate ambiguity ... computers do not!) Instead, let all such identifiers be column-values stored somewhere in the database, possibly (or, not ...) indexed by a UNIQUE key to prevent duplicates.

I recommend that all primary keys should be completely abstract, containing no meaning at all. For instance, a UUID could be used. Within the database, auto-incrementing integers can be used.

Answer 2

SSN is not a unique identifier for people. Whether it should be the PK in some table depends on what the rows in the table mean. (See also sqlvogel's answer.)

6.1 percent of Americans have at least two SSNs associated with their name. More than 100,000 Americans have five or more SSNs associated with their name. [...] More than 15 percent of SSNs are associated with two or more people. More than 140,000 SSNs are associated with five or more people. Significantly, more than 27,000 SSNs are associated with 10 or more people.
--idanalytics.com

See also Wikipedia Social Security number.

Answer 3

Keys can only be determined from business rules. What matters is whether it makes sense in the context of your business requirements to enforce uniqueness of SSN or not. That is not a matter your DBA alone can decide on. It's something on which to consult the HR department or whoever else uses this data.

Assuming that your table will have at least one key (perhaps more than one) then I suggest that the DBA is in the best position to advise on the policy for primary keys. If the choice of a primary key is of any importance at all then the DBA ought to say so.