4 ms·

In Sweden, almost everyone is assigned a number at birth, a personnummer, with the format YYMMDD-NNNN (or YYYYMMDDNNNN in computing, to avoid having a Y2K issue

In Sweden, almost everyone is assigned a number at birth, a personnummer, with the format YYMMDD-NNNN (or YYYYMMDDNNNN in computing, to avoid having a Y2K issue every time someone turns 100). A lot of computer systems here seem to treat it as a natural key, which is a terrible idea, because: • Not everyone has one (notably, asylum seekers and temporary residents don't), so if you rely on them, you're excluding those people. • They can change. They won't for 99.9% of people, but not everyone is so lucky. If you use these as your primary key, you're going to create a headache for you and your users for that 0.1% of cases.

jackjeff 3y ago
I think that's true for Social Security numbers in France/US, and National Insurance numbers in UK. About 15 years ago, after working in Germany I came back to France for a couple of years, the country where I was born / assigned a number at birth / following a similar pattern with the year in the code. My health insurance from Germany did not transfer according to EU rules or something, at least that's what the regional French National Security told me. The way they got me out of the Kafkaesque situation was to give me a "temporary" social security number, like they would give a foreign immigrant, and have it revert back to my "normal" number after 3 months. At some point I had "two" national security numbers. It was a real mess to fix the whole thing afterwards as you can imagine, and considered I left the country only after a couple of years, I wonder why I even bothered.
- tough 3y ago
  French bureaucracy will kill your soul slowly but surely
c00lio 3y ago
Yes, but what would be the alternative? Of course you can use artificial keys like a random UUID for each of your db objects. Which will work quite well if you only interact with your own system. But as soon as one of your db objects needs to be linked to some other system, you will need some common ground for a correlation, and something like a personnummer will help immensely and solve 99.9% of your problems. The 0.1% of problematic cases is far less than the headaches that the absence of some common ID scheme will cause you. Imagine e.g. having to correlate on the usual "Name, First Name, Birth Name, Place of Birth, Date of Birth" dance: My place of birth used to be called Lower Unxton at the time of my birth, now it has been reformed with Upper Unxton and Exampleville into Greater Unxton. Which one do you want? Did I always give the same answer to that question? My parents also divorced and my birth name legally changed. Do you want the old or the new birth name? Btw., my legal date of birth is actually in a non-gregorian calendar. How do I input that into your form field, it doesn't seem to like Showa 50 as a year, not even to speak about the proper characters? I'd claim any imperfect personnummer is still far superior to all the problems one would have without it.
- cpfohl 3y ago
  They’re not suggesting you don’t store it… I don’t think you’re addressing the real concerns here. How I read the concerns: External connections to your data belong in a field or a separate table to ensure that your data is not so tightly coupled to the key you’ve chosen that you limit your data model’s expressive power. Don’t make an external identifier the primary key in your database.
  - c00lio 3y ago
    Ah. Thanks for the explanation. With that I agree completely.
- vaylian 3y ago
  > Yes, but what would be the alternative? Not have a nation-wide ID scheme. The problem is that people will rely too much on it being always correct and a lot of infrastructure will grow on top of it so that it is really hard to fix things. A better approach is to keep the human in the loop. If a government or a company wants to create a connection between databases, let the human whose data is requested, provide the external keys/IDs upon request. That's less automation, but it allows for more flexibility and better personal data protection.
  - wolfgang42 3y ago
    We tried that in the US, and we ended up with an ad-hoc one anyway. It seems to be far too useful of a concept in modern society to avoid this happening whether you want it to or not.
  - emodendroket 3y ago
    Yeah the US system of hijacking numbers that were never meant for this purpose and treating them as sufficient to take out credit in your name, and then having fifty redundant DMVs handling identification cards makes much more sense.
- Groxx 3y ago
  You deal with it the same way as you deal with any value that may change and may not be unique: you don't make it your primary key. Just index it separately, and resolve your links at insertion time to your internal actually-stable-and-unique keys. Then when your system runs into one of these duplicates you can tell what is happening, and you have a chance to fix it, rather than blindly plowing ahead and ruining even more data. None of this has anything to do with how you represent your API to other systems. Do whatever you need there. And if system X is confused and thinks public-ID-Y is actually Z, well now you can handle it - that's just another discriminator, but you select this one based on the querier.
Phelinofist 3y ago
In what cases can this number change?
- meithecatte 3y ago
  Poland has a very similar numbering system, the PESEL. It can change if the date of birth was recorded inaccurately and you need to correct it, or, because the PESEL encodes gender, when you get your gender marker legally changed.
  - playingalong 3y ago
    PESEL system was bought from Sweden.
- Philpax 3y ago
  The personnummer encodes gender in the last digit (which, IMO, is very silly) - so when that changes, the number has to change too.
  - hgsgm 3y ago
    That explains all the fuss of recent years. Transgenderism is an affront against data schematization.
- TazeTSchnitzel 3y ago
  Gender change, incorrectly recorded time of birth, duplicate number (though that one hasn't happened in the last 30 years or so), replacement of a temporary number with a permanent number. The extreme case is witness protection, but in that case only the police would even know about the connection.
Pamar 3y ago
Personally I think this is very bad idea especially because it would be be very tempting to use the id to - for example - trivially "decide" if you can, for example, smoke, drink alcohol, watch porn. But this would also make some tricks to extend the scheme to corner cases (e.g.: refugees will get YYMMDD-NNNN where the date part is when they were registered at entry) fail miserably. At the very least, a single letter code in the mix would mitigate the problems a bit.
BlueTemplar 3y ago
I'm curious, was there any pushback to its introduction ? In France, when the government tried to introduce something like this in 1973, it (eventually) caused a scandal (after a scathing Le Monde article), which resulted in the whole project being scrapped, and the French data protection authority CNIL being created : https://www.lemonde.fr/blog/bugbrother/2010/12/23/safari-et-la-nouvelle-chasse-aux-francais/ https://www.lemonde.fr/blog/bugbrother/2010/12/23/safari-et-... (fr) (CNIL was later defanged in 2004.)
schlowmo 3y ago
Not so long ago I had to deal with the Austrian version of a Social Security Number and it turns out that using birthdates inside such a number isn't a good idea, since * Some people doesn't have a birthdate with which the Austrian state agrees * For those people the Austrian state at least assumes a birthyear with a birthday at January 1st or July 1st * This leads to overflowing the available numbers for those two dates * If a date overflows, they get SSN with month "13“. The 13th month can have as many days as needed (so > 31 is possible). * Now you have SSNs with a month part of e.g 2023-13-32. Why even bother with birthdates then?
ttepasse 3y ago
Should’t there be discussion about changing this number scheme? According to Wikipedia the NNNN part is really NNGC. C is a checksum, giving NNG as a serial number with G even/odd for gender. Sweden seems to have ca. 115000 births per year, making 315 births per day. But those may not be evenly distributed. The available space or serial numbers seems awfully close.
- TazeTSchnitzel 3y ago
  Yes, there's only about 500 numbers per legal gender per day. There are overflows on certain dates and so some people get assigned a number with a slightly wrong birthdate. As inconvenient as this is for those individuals, it'd be a lot of work for society at large to move to a new system, so it's probably never going to happen.
sebastialonso 3y ago
Any scheme that covers 99.9% of cases is a success, something quite hard to achieve. Calling it a terrible idea is a bit melodramatic, no?

jackjeff 3y ago

I think that's true for Social Security numbers in France/US, and National Insurance numbers in UK. About 15 years ago, after working in Germany I came back to France for a couple of years, the country where I was born / assigned a number at birth / following a similar pattern with the year in the code. My health insurance from Germany did not transfer according to EU rules or something, at least that's what the regional French National Security told me. The way they got me out of the Kafkaesque situation was to give me a "temporary" social security number, like they would give a foreign immigrant, and have it revert back to my "normal" number after 3 months. At some point I had "two" national security numbers. It was a real mess to fix the whole thing afterwards as you can imagine, and considered I left the country only after a couple of years, I wonder why I even bothered.

tough 3y ago
French bureaucracy will kill your soul slowly but surely

c00lio 3y ago

Yes, but what would be the alternative? Of course you can use artificial keys like a random UUID for each of your db objects. Which will work quite well if you only interact with your own system. But as soon as one of your db objects needs to be linked to some other system, you will need some common ground for a correlation, and something like a personnummer will help immensely and solve 99.9% of your problems. The 0.1% of problematic cases is far less than the headaches that the absence of some common ID scheme will cause you. Imagine e.g. having to correlate on the usual "Name, First Name, Birth Name, Place of Birth, Date of Birth" dance: My place of birth used to be called Lower Unxton at the time of my birth, now it has been reformed with Upper Unxton and Exampleville into Greater Unxton. Which one do you want? Did I always give the same answer to that question? My parents also divorced and my birth name legally changed. Do you want the old or the new birth name? Btw., my legal date of birth is actually in a non-gregorian calendar. How do I input that into your form field, it doesn't seem to like Showa 50 as a year, not even to speak about the proper characters? I'd claim any imperfect personnummer is still far superior to all the problems one would have without it.

cpfohl 3y ago
They’re not suggesting you don’t store it… I don’t think you’re addressing the real concerns here. How I read the concerns: External connections to your data belong in a field or a separate table to ensure that your data is not so tightly coupled to the key you’ve chosen that you limit your data model’s expressive power. Don’t make an external identifier the primary key in your database.
- c00lio 3y ago
  Ah. Thanks for the explanation. With that I agree completely.
vaylian 3y ago
> Yes, but what would be the alternative? Not have a nation-wide ID scheme. The problem is that people will rely too much on it being always correct and a lot of infrastructure will grow on top of it so that it is really hard to fix things. A better approach is to keep the human in the loop. If a government or a company wants to create a connection between databases, let the human whose data is requested, provide the external keys/IDs upon request. That's less automation, but it allows for more flexibility and better personal data protection.
- wolfgang42 3y ago
  We tried that in the US, and we ended up with an ad-hoc one anyway. It seems to be far too useful of a concept in modern society to avoid this happening whether you want it to or not.
- emodendroket 3y ago
  Yeah the US system of hijacking numbers that were never meant for this purpose and treating them as sufficient to take out credit in your name, and then having fifty redundant DMVs handling identification cards makes much more sense.
Groxx 3y ago
You deal with it the same way as you deal with any value that may change and may not be unique: you don't make it your primary key. Just index it separately, and resolve your links at insertion time to your internal actually-stable-and-unique keys. Then when your system runs into one of these duplicates you can tell what is happening, and you have a chance to fix it, rather than blindly plowing ahead and ruining even more data. None of this has anything to do with how you represent your API to other systems. Do whatever you need there. And if system X is confused and thinks public-ID-Y is actually Z, well now you can handle it - that's just another discriminator, but you select this one based on the querier.

Phelinofist 3y ago

In what cases can this number change?

meithecatte 3y ago
Poland has a very similar numbering system, the PESEL. It can change if the date of birth was recorded inaccurately and you need to correct it, or, because the PESEL encodes gender, when you get your gender marker legally changed.
- playingalong 3y ago
  PESEL system was bought from Sweden.
Philpax 3y ago
The personnummer encodes gender in the last digit (which, IMO, is very silly) - so when that changes, the number has to change too.
- hgsgm 3y ago
  That explains all the fuss of recent years. Transgenderism is an affront against data schematization.
TazeTSchnitzel 3y ago
Gender change, incorrectly recorded time of birth, duplicate number (though that one hasn't happened in the last 30 years or so), replacement of a temporary number with a permanent number. The extreme case is witness protection, but in that case only the police would even know about the connection.

Pamar 3y ago

Personally I think this is very bad idea especially because it would be be very tempting to use the id to - for example - trivially "decide" if you can, for example, smoke, drink alcohol, watch porn. But this would also make some tricks to extend the scheme to corner cases (e.g.: refugees will get YYMMDD-NNNN where the date part is when they were registered at entry) fail miserably. At the very least, a single letter code in the mix would mitigate the problems a bit.

BlueTemplar 3y ago

I'm curious, was there any pushback to its introduction ? In France, when the government tried to introduce something like this in 1973, it (eventually) caused a scandal (after a scathing Le Monde article), which resulted in the whole project being scrapped, and the French data protection authority CNIL being created : https://www.lemonde.fr/blog/bugbrother/2010/12/23/safari-et-la-nouvelle-chasse-aux-francais/ https://www.lemonde.fr/blog/bugbrother/2010/12/23/safari-et-... (fr) (CNIL was later defanged in 2004.)

schlowmo 3y ago

Not so long ago I had to deal with the Austrian version of a Social Security Number and it turns out that using birthdates inside such a number isn't a good idea, since * Some people doesn't have a birthdate with which the Austrian state agrees * For those people the Austrian state at least assumes a birthyear with a birthday at January 1st or July 1st * This leads to overflowing the available numbers for those two dates * If a date overflows, they get SSN with month "13“. The 13th month can have as many days as needed (so > 31 is possible). * Now you have SSNs with a month part of e.g 2023-13-32. Why even bother with birthdates then?

ttepasse 3y ago

Should’t there be discussion about changing this number scheme? According to Wikipedia the NNNN part is really NNGC. C is a checksum, giving NNG as a serial number with G even/odd for gender. Sweden seems to have ca. 115000 births per year, making 315 births per day. But those may not be evenly distributed. The available space or serial numbers seems awfully close.

TazeTSchnitzel 3y ago
Yes, there's only about 500 numbers per legal gender per day. There are overflows on certain dates and so some people get assigned a number with a slightly wrong birthdate. As inconvenient as this is for those individuals, it'd be a lot of work for society at large to move to a new system, so it's probably never going to happen.

sebastialonso 3y ago

Any scheme that covers 99.9% of cases is a success, something quite hard to achieve. Calling it a terrible idea is a bit melodramatic, no?