There are many DBMSes that combine columns into a singular primary key. Performance tradeoffs vary, especially when it comes to indexing.

Any pure relational database design will eschew surrogate keys - most real-world systems will (should) add them back - because a surprising number of good natural keys end up changing (names change, phone numbers change, emails change, twitter handles become irrelevant/disappear, location of birth may change subject to geographic regions changing size...).

And on top of all that, there are efficiency concerns.

That said, at least for join tables AFAIK - there aren't often a need for row IDs beyond the involved foreign keys - unless you need to add meta data from other relations/tables...

> location of birth may change

My British passport says I was born in Birr; my Irish passport says I was born in Galway. These are both correct, because they are answering different questions. (I was born in the town of Ballinasloe in County Galway, but my mother's place of residence at the time of my birth was the town of Birr in County Offaly.)

So British place of birth means "mother's residence" and not place of birth?

Official guidances here: https://assets.publishing.service.gov.uk/government/uploads/...

Could maybe be just a mistake when doing the UK registration ? It's an easy fix if wanted.

> Could maybe be just a mistake when doing the UK registration ? It's an easy fix if wanted.

Changes! lol

That's my memory of it. My British passport is expired, and is probably somewhere in my parents' house. I don't actually know what it says on it. I do clearly remember that at least one British form of ID I had at one time recorded my mother's place of residence rather than my actual birth place. I thought it was the passport. Maybe I was wrong.