Even that makes no sense.
You would use the SSN as primary key, and thus multiple entries for the same SSN would not be possible.
No, my point is that Elon talks about de-duplication, while he should actually say: who the FUCK designed this database to even ALLOW this in the first place.
but it should be unique, because that's what it is.
and you could easily make sure that this is always the case either by having a table with the SSN being the primary key, OR setting a unique index for the SSN field.
>SSNs are reused.
https://www.ssa.gov/history/hfaq.html
Q20: Are Social Security numbers reused after a person dies? A: No. We do not reassign a Social Security number (SSN) after the number holder's death.
No, it's shitty database design.
Take a hospital system. Every patient gets a unique number called the patient number, plus multiple case numbers.
All of these are primary keys, because you never want to assign the same number to multiple people.
Same here. It makes no sense to assign the same SSN to multiple people, ever. And there is no way you will ever run out of numbers.
that's the CASE number, which is also unique.
every patient has one number.
every patient gets one or multiple case numbers ("encounters").
should he get another number, then these numbers should be combined, but it's still unique numbers.
>Primary keys slow databases down, especially write time. They are not meant to be all over your database.
What?
A primary key simply lets a database identify every row uniquely. In professional systems like for example SAP, every table has to have a primary key.
What's true though is that additional indexes will increase write time.
additional indexes can improve all sorts of read operations, especially for big tables.
most of the time database tables are read a lot, and write operations do not happen often.
you want read operations to work as fast as possible.
but this is also about database design.
let's go back to the hospital.
if you are a bad database designer, you would store it like this:
Case-data-table:
Primary key: PATIENT + CASE
this would allow the same case number to be accidentally get assigned to multiple patients. This would be very very bad.
Therefore you do this instead:
Primary key: CASE
Regular field: PATIENT
this way every case number has to be unique, there is no way around that, and every case can only get assigned to one single patient, which is very important.
of course some systems like SAP HANA loads the whole database into RAM, in that case such indexes are not needed, at the same time when the system goes down, it may take a day to come back up. With a regular SQL database, that's not the case.
the images are on both servers.