I think somewhat different than the article in some ways.
The first example is why `UPDATE CASCADE` was implemented. So it's possible to use natural keys as identity without the fear of children table. At least in most databases it works.
The drawback of enumeration is real, so if you expose this key you'll need some authentication/ authorization mecanism.
Another good thing in natural keys is that you can eliminate part of the joins. You don't have to join the father table because the key in child table is known.
I think the biggest challenge is how to map logins to people. It's very common to interpret both as the same, but they are not.
> The first example is why `UPDATE CASCADE` was implemented. So it's possible to use natural keys as identity without the fear of children table. At least in most databases it works.
This is only true in a system using a single database, not replicating data in external services, and not offering APIs.
And while it might work today when the service/website is still fairly small and self contained, the requirements might change at any time. So the title (You will [future] regret it) still applies to this solution
The first example is why `UPDATE CASCADE` was implemented. So it's possible to use natural keys as identity without the fear of children table. At least in most databases it works.
The drawback of enumeration is real, so if you expose this key you'll need some authentication/ authorization mecanism.
Another good thing in natural keys is that you can eliminate part of the joins. You don't have to join the father table because the key in child table is known.
I think the biggest challenge is how to map logins to people. It's very common to interpret both as the same, but they are not.