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.