How does this pic show that Elon Musk doesnt know SQL?

Take this with a grain of salt as I'm not a dev, but do work on CMS reporting for a health information tech company. Depending on how the database is designed an SSN could appear in multiple tables.

In my experience reduplication happens as part of generating a report so that all relevant data related to a key and scope of the report can be gathered from the various tables.

Beat me to asking this follow up, though you linking additional resources is probably more effort that I would have done. Thanks for that!

My guess would be around your note. If someone mistakenly has two SSNs (due to fraud, error, or name changes), combining DOB helps detect inconsistencies.

Some other possibilities, and I'm just throwing out ideas at this point:

• Adding DOB could help with manual lookups and verification.
• Using SSN + DOB ensures a standard key format across agencies, making it easier to link records.
• Prevents accidental duplication if an SSN is mistyped.
• Maybe the databases were optimized for fixed-length fields, and combining SSN + DOB fit within memory constraints.
• It was easier to locate records with a “human-readable” key. Where as something like a UUID is harder for humans to read or sift through.

If it's used as an identifier to link together rows from different tables. Also known as "joining" tables. SSN (with birthdate) is a unique identifier, and so it's natural to choose as a primary/foreign key.

It doesn't matter without scope. Are we looking at a database of SSNs? tax records? A sign in log? The social security number database might require uniques in some way, but tax records could be the same person over multiple years. A sign in gives a unique identifier but you could be signing in every day.

It's like saying a car VIN shows up multiple times in a database. Where? What database? Was it sold? Tickets? Registered every year?

This is nothing more than a "assume I mean immigrants or tax fraud and get mad!" inflammatory statement with no proof or reason.

Hypothetically you could have a separate "previous names" table where you keep the previous names and on the main table you only keep the current name. There are a lot of ways to design a db to not unnecessarily duplicate SSNs, but without knowing the implementation it's hard to say how wrong Musk is. But it's obvious he doesn't know what he's talking about because we know that due to human error SSN-s are not unique and you can't enforce uniqueness on SSN-s without completely fucking up the system. Complaining about it the way he did indicates that he doesn't really understand why things are the way they are.

It's true that some Americans don't have Social Security numbers, but those Americans can't collect Social Security benefits unless/until they get one.

Yeah. And the fix for that has nothing to do with "de-duping" as a database operation either.

The main components would probably be:

1. Decide on a new scheme (with more digits)
2. Create a mapping from the old scheme to the new scheme. (that's where existing duplicates would get removed)
3. Let people use both during some transition period, after which the old one isn't valid any more.
4. Decide when you're going to stop issuing old SSNs and only issue new ones to people born after some date.

There's a lot of complication in each of those steps but none of them are particularly dependant on "de-duped" databases.

Just read the format of the us ssn in that wikipedia. That wasnt a smart format to use lol. Only supports 99*999 ( +/- 100k ) people per area code. No wonder numbers are reused.
In some countries its birthday+sequence number encoded with gender+checksum and that has been working since the 80's.
Before that was a different number, but it wasnt future proof like the us ssn so we migrated away in the 80's :')

Pandas and Pickle man….

Yeah, a better explanation is that Deduplicating Databases are an absolutely terrible idea for every use case, as it means deleting history from the database.

Assuming the whole "duplicate SSN" thing isn't just a complete fabrication, we have no idea what table he was even looking at! A table of transactions e.g. would have a huge number of duplicate SSNs.

I mean I don't know a ton about SQL but one thing to keep in mind about SSNs is they were not originally meant to be used for identification but because we have no form of national id and places still needed a way to verify who you are people just started using SSNs for that since it's something everyone has and there wasn't really a better option. So now the government has been having to try and make them work for that and make them more secure. The better solution would be to make some form of national id that is designed to be secure but Republicans and people like Musk would probably call that government overreach or a way to spy and track people.

My wife has a tax payment history under two different legal names which share a single SSN

This is from 15 years ago, so I don't know how much has changed since then. But this sounds like the sort of thing they mean.

https://www.nbcnews.com/technolog/odds-someone-else-has-your-ssn-one-7-6c10406347

I'd imagine the numbers of dead people eventually get cycled around to. 9 digits only gives you 999,999,999 people to go through, and we have over a third of that in existence right now.

AF1 probably needs a database just for it's in in-flight menu.

He didn't say the SSN database isn't SQL. He said the GOVERNMENT doesn't use SQL.

SSNs being duplicated would be entirely expected depending upon the table's purpose. There are many forms of normalization in database tables.

I mean just think about this a little bit, if the purpose is transactions or something and each row has a SSN reference in it for some reason, you'd have a duplicate SSN per transaction row.

A tiny bit of learning SQL and you could easily see transactional totals grouped by SSN (using, get this, a group by clause). This shit is all 100% normal depending upon the normalization level of the schema. There are even -- almost obviously -- tradeoffs between fully normalizing data and being able to access it quickly. If I centralize the identities together and then always only put the reference id in a transactional table, every query that needs that information has to go join to it and the table can quickly become a dependency knot.

There was a "member" table for instance in an IBM WebSphere schema that used to cause all kinds of problems, because every single record was technically a "member" so everything in the whole system had to join to it to do anything useful.

Oh, well another user pointed out that SSN's are not unique, I think they are recycled after death or something. In any case, I do know that when the SSN system was first created it was created by people who said this is NOT MEANT to be treated as unique identifiers for our populace, and if it were it would be more comprehensive than an unsecure string of numbers that anyone can get their hands on. But lo and behold, we never created a proper solution and we ended up using SSN's for identity purposes. Poop.

Fair point, I've edited the answer to be clearer for future readers.

I've had a poor experience with btrfs dedupe tbh (and a terrible experience with qgroups), however, this was years ago. Btrfs snapshots I prefer though, much easier not to have that dependence.

What distro are you using for ZFS, void?

I have a fraction of a brain, I think, and use ChatGPT as a guide so that I have something to start with. Even if it's slightly off, my two brain cells can pick it out and go from there. It's not so bad.

And you know, I get it if you don't like AI, but let's be honest about it at the very least.

I disagree, it's just a tool. It's a fantastic way to template applications very quickly, particularly for those who are not already familiar with technologies and may not have the time or opportunity to play around with things otherwise.

Llm is not a search engine and it can produce awful code. This is not production code, it's for tinkering. As a sandbox tool, LLMs are fantastic.

On the ethical side of things, yeah openAI sucks, Qwen2.5 would be up to this task, one can run that locally.

I think what he means is that the unique identifier for a database record is a composite of two fields: SSN + birth date. That doesn’t mean that SSN to birth date is a one-to-many relation.

A weak example would be my grandma. She was born before social security and was told as a kid she was born in 1938. Because I guess in the olden days, you just didn't need to pass your birth certificate around for anything, it wasn't until she went to get married at ~age 25 that she needed her birth certificate and when she got it, it actually said she was born in 1940 (I forget the actual years, but I remember it was a two year and two day gap between dates).

Its a weak example that should apply to only a microscopic portion of the population, but I could see her having some weird records in the databases as a result.

Edit: brain dropped out and I forgot part of a sentence.

Well, if someone changes their name you'd add a new record with the same SSN to hold their new name, that way it keeps the records consistent with the paperwork; old papers say their old name and reference the retired record, new papers use their new name and reference the new record.

You can use the SSN as the key to find all records associated with a person, it doesn't have to be a single row per SSN, in fact that would make the data harder to manage and less accurate.

E.g. if someone changes their last name after getting married, it could be useful to be able to have their current and former name in the database for reference.

Another commentor pointed out a legitimate use case, but it's not even worth thinking about that much. De-duplocated is usually a word you use in data science to talk aboutakong sure your dataset is "hygienic" and that you aren't duplicating data points. A database is much different because it is less about representing data, and more about storing it in a way that allows you to perform transactions at scale - retrieval, storage, modification, etc. Relational databases are analyzed in terms of data cardinality which essentially describes tradeoffs in representation between speed of retrieval (duplications good) vs storage efficiency (duplications bad).

The issue is that Elon is so vague and so off the mark that it is very hard to believe that he even has the first clue about what he is a talking about. Even you are confused just by reading it. It is all a tactic to convince others that he is smarter than he is while doing extreme damage to the hardworking people that actually make this stuff possible. Have you noticed that the man has never come to a conclusion that wasn't in his interests? This is not honest intellectualism, or discussion based on technical merit. It's self serving propaganda.

As read on wikipedia ( https://en.wikipedia.org/wiki/Social_Security_number ) the format only allows +/- 100k numbers per area code ( which is also limited to 999 codes? ), so over time you are forced to reuse some codes. In total the format allows 99m unique codes, and the us currently has 334mil people sooooo :')

Big thing I’m prying at is whether there would be a legitimate purpose to have duplicated SSNs in the database

formally, changing the identity of someone would have a very explicit reason to keep a "duplicate" ssn entry, if purely for historical reasons for example. I'm sure there are a myriad of technical reasons to be doing this.

Because everyone hates IPv6?

Why not reuse SSN that are no longer are in service for whatever reason?

After his own offer to rescue the children was turned down

Well, there’s not always a benefit to keeping historical data. Sometimes you only want the most up-to-date information in a particular table or database, so you’d just update the row (replace). It depends on the use case of a given table.

in this case you would just overwrite the existing row, you wouldn't use de-duplication because it would do the opposite of what you wanted in that case. Maybe even use historical backups or CoW to retain that kind of data.

Elon believes that each row in a table should be unique based on the SSN only, so a given SSN should appear only once with the person’s name and details on it. Yes, it’s an extremely dumb idea, but he’s a famously stupid person.

and naturally, he doesn't know what the term "de-duplication" means. Definitionally, the actual identity of the person MUST be unique, otherwise you're going to somehow return two rows, when you call one, which is functionally impossible given how a DB is designed.

Ssn being unique isnt a dumb idea, its a very smart idea, but due to the us ssn format its impossible to do. Hence to implement the idea you need to change the ssn format so it is unique before then.

Also, elons remark is stupid as is. Im sure the row has a unique id, even if its just a rowid column.

As someone explained in another comment, you often duplicate information due to rules around cardinality to gain improvements in retrieval an. structure. I would be pretty worried if SSSNs were being used as a a widepread primary key in any set of tables - those should generally be UUIDs that can be optimized for gashing while avoiding collisions.

Even if we are being generous to Elon, we could assume that social security payments are processed on mainframes given how many have to go out and the legacy nature of the program. Most mainframe shops I know have adapted an SQL interface for records in some capacity, but who knows what he is looking at.

Government federal IT is done at a per agency basis. I would say oracle database is pretty much the most licensed piece of software the government does use outside of Redhat Linux and windows desktop.

Indeed, that's a possibility, but I'm not privy to the structure of the social security administration's databases so I couldn't say if it was indeed the case.

The deeper point being, if the government has any databases at all, then some form of Structured Query Language is being used to read and write it.

Seems to me that the most generous interpretation would be the preponderance of Oracle's DBs in the government, and Musk being pedantic since they aren't literally called "SQL" like MySQL, MSSQL, or PostgreSQL (even though most Oracle DBs still fall into that category).

Excel is accounting workbook software, it is not suitable for data storage. Although people certainly use it that way.

It makes a pretty good calculator. 🧮

It's an amazing tool if only one person is updating / maintaining the file. The moment collaboration starts, you're all fucked. I'm currently maintaining one that I inherited that is at least 10 years old and comes with a 50 page instruction manual on how to run it every month... that then gets posted to a shared drive where anyone can edit.

And then the rest of the month is spent explaining to the end users how they fucked it up this time.

On the flip side, I've also built sheets that could parse data between Nav, MySQL, and SQL ERP systems with tables of over 5million rows each on a single button refresh that ran flawlessly for years... because I was the only maintainer and the sheets were locked from accepting changes from other users.

Sure, basically any time you have a many-to-many relationship you'll have to repeat keys multiple times. Think students taking courses. You'd have a students table and a courses table, but the relationship is many students take many courses. So you'd want a third table for lookups where each row is [student_id, course_id].

This stackoverflow post has a similar example with authors and books - https://stackoverflow.com/questions/13970628/how-do-i-model-a-many-to-many-relation-in-sql-server#13970688

Thanks, OP seemed more curious about the technical aspects than just the absurdity of the comment (since pretty much every business uses SQL) so hoped a more technical explanation might be appreciated.

His post (if we believe it) demonstrates he must have access to both pieces of information.

At best he is referring to an older mainframe he is aware of not being sql while being completely oblivious of all the government systems that are in sql.

Which isn't giving him any credit, because in that case he is atill running his mouth based on being ignorant about other government systems.

I submitted data to a government database yesterday that I know for a fact is sql because we have had an ongoing years long relationship that involves improving that system and aligning our state level sql database. The government absolutely uses sql frequently, even if they still have older mainframes with some other database architecture.

Not unless the data associated with that SSN is itself inconsistent.

For example, when multiple people are fraudulently using the same SSN, the fraud monitoring DB would neccessarily need to record several entries with the same SSN.

Wow, that's fucked.

Oh, I hear you!

I think the thing that's catching you up the most is that you're assuming Elon has the slightest clue what he's talking about about. In your mind, you've read the words "the social security database" from his post and have made assumptions about what that means.

I've worked with databases for 20+ years, several of those being years working on federal government systems. Each agency has dozens or possibly hundreds of databases all used for different purposes. Saying "the social security database" is so fucking general that it's basically nonsensical. It'd be like saying "Ford's car database".

Elon clearly heard someone technical talking about something, then misinterpreted it for his own purposes to justify what he is doing by destroying our government institutions. His follow up of saying the government doesn't use SQL just reinforces that point.

Trying to logically backtrack into what he actually meant - and what the primary keys should be - is just sane washing an insane statement.

That all makes sense, except if someone's SSN changes (which happens under certain circumstances), doesn't that invalidate their primary key or require a much more complicated operation of issuing a new record and relinking all the existing relationships?

I can imagine an SSN existing in more than one primary key due to errors. If they use SSNs in the primary key at all, but combined with something else, that leads me to believe that the designers felt that SSNs were reliable for being a pure primary key.

I agree with you about Occam's Razor. The guy has demonstrated multiple times that he's a dishonest moron.