DahGangalang

Naw, I definitely meant to be asking about duplication of data in databases (vs if the government actually uses SQL).

Sorry to have communicated that so poorly. Everyone seems to be taking the angle you're arguing though. Guess I'll need to work on that.

Ugh, YES, I am so frustrated at the counter arguments for this that I constantly hear spouted by my (ultra-conservative) family.

I hope that notion re-enters the public consciousness as a part of this (not holding my breath tho)

Hmmm, well I can't speak to how the actual databases are put together, so maybe they would have that as two separate unique primary keys with a duplicated SSN.

But it really seems like bad design if they out it together that way....

Yeah, obviously ol' boy is tripping if he thinks SQL isn't used in the government.

Big thing I'm prying at is whether there would be a legitimate purpose to have duplicated SSNs in the database (thus showing the First Bro doesn't understand how SQL works).

Yeah, obviously ol' boy is tripping if he thinks SQL isn't used in the government.

Big thing I'm prying at is whether there would be a legitimate purpose to have duplicated SSNs in the database (thus showing the Vice Bro doesn't understand how SQL works).

I'm not aware of any instance where two people share an SSN though. The Social Security Administration even goes as far as to say they don't recycle the SSNs of dead people (its linked a couple times in other comments and Voyager doesn't let me save drafts of comments, I'll make an edit to this comment with that link for you).

Can you point me to somewhere showing multiple people can share an SSN?

Edit: as promised: The Social Security FAQ page

Yeah, I can imagine thats be an administrative headache. I do not envy them the opportunity of sorting that out.

Thanks for the example though. That makes sense.

I'm not familiar with cases where someone's SSN could change. Could you link to resources on when that would happen?

I think I was getting some wires crossed and/or misunderstood what geoff (parent commentor to my last comment) was saying, so my comment may be misdirected some.

But according to The Social Security FAQ page, SSNs are not recycled, so that data (especially when compounded and hashed with other data) should be able to establish a one-to-one relationship between each primary key and an SSN, thusly having SSNs appear associated with multiple primary keys is a concern.

Other comments have pointed to other explanations for why SSNs could appear to occur multiple times, but those amount to "it appeared in a different field associated with the same primary key". I think thats the most likely explanation of things.

Yeah, no one appreciates security.

I probably overused that saying to explain it: 'if theres no break ins, why do we pay for security? Oh, there was a break in - what do we even pay security for?'

Yeah, databases are complicated and make my head hurt. Glancing through resources from other comments, I'm realizing I know next to nothing about database optimization. Like, my gut reaction to your comment is that it seems like unnecessary overhead to have that data across two tables - but if one sub-dept didn't need access to the raw SSN, but did need access to less personal data, j could see those stored in separate tables.

But anyway, you're helping clear things up for me. I really appreciate the pseudo code level example.

Thats how I feel too.

Lol, I'd love to see the data hes trying to speak about (not that that'd be any kind of concerning for privacy /s). I don't think he's outright lying, but it definitely feels like a misrepresentation / wrong conclusion from the data.

But thanks for your part in helping me understand all this!

From what I'm seeing in other comments, it seems SSNs aren't used as primary keys, but they are part of generating the primary key. I haven't seen anyone directly say it, but it sounds like the primary key is a hash of SSN + DOB (I hope with more data to add entropy, because thats still a tiny bit of data to build a rainbow table from).

Still, assuming we haven't begun re-using SSNs, it seems concerning to me that a SSN is appearing multiple times in the database. It seems a safe assumption that the uniqueness of a SSN should make the resultant hash unique, so a SSN appearing as associated to multiple primary keys should be a concern, right?

Other comments have led me to believe the "duplicate SSNs" are probably appearing in "different fields" (e.g. a dead man's SSN would appear directly associated to him, but also as a sort of "collecting payments from" entry in his living wife's entry). That would a misrepresentation of the facts (which we know Vice Bro, Elon Musk the Wise and Honest would never do). Occam's Razor though has me leaning in that direction.