[dragonwriter]

> > Now, sometimes a table has a natural primary key, for example the social security number of a country’s citizens.

> You know, you think that, but it's never that simple.

It’s that simple if you’re the Social Security Administration and its a table of Social Security Accounts, not people.

Other than that, using SSNs as a primary key is just plain wrong.

[Izkata]

> It’s that simple if you’re the Social Security Administration and its a table of Social Security Accounts, not people.

Nah, they keep track of duplicate usage: https://www.nbcnews.com/technolog/odds-someone-else-has-your...

> The IRS often knows when this happens, when the imposter pays taxes. The Social Security Administration knows, too, for the same reason. And the nation's credit bureaus usually know, because the imposter often ends up applying for some form of credit. Plenty of financial institutions also have access to this information.

[chrischen]

Maybe using them as passwords is what's wrong.

[squiggleblaz]

How do you cope if you want to record people who don't have an SSN or equivalent? (e.g. I have none, because the country of my citizenship doesn't issue anything comparable)

Or if you're expanding to countries whose SSNs clash with each other?

SSN as PK is wrong regardless of whether you're doing SSN as password.

[iratewizard]

Right? Credit card numbers as a primary key is far more efficient.