4 ms·
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
by 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 agoThey’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 agoAh. 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 agoWe 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 agoYeah 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 agoYou 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.