Aren't life expectancy at birth figures heavily skewed by infant mortality rates. I think this is quite a commonly misunderstood statistic for this reason. So while it's true that in the past a new born baby's chances of becoming a great grandparent were much lower than they would be today, that would mainly be due to the low chances of them ever reaching adulthood and becoming a parent at all, rather than the chances of parents living beyond 47.
Exactly. While life expectancy from adulthood (say 20 yo) has increased (i.e. UK males have gone from expected average 60y to 80y between 1841 to 2011 [1]), it hasn't increased nearly as much as the life expectancy from birth (i.e. 33% vs 98% increase over that period).
I thought this as well, but I did a little research before responding, and it looks like even though this is broadly true, people still weren't living particularly long before the modern era. For example, in Ancient Greece, a man who lived to 15 would expect to live to 37-41 years, in Rome if a man made it to 20 they could expect to live to 60, in the late medieval if you made it to 25 you could expect to live to ~48 [0]. You still need to make it to 60 to be a great grandparent, assuming you and your kids are having kids at ~15 years of age (edit: and that might be a friendly assumption given how high infant mortality was).
There's some uncertainty about this, and while not properly controlled for obvious reasons, a study of lives of men of renown in 5th and 4th century Greece found a median life expectancy of around 70: https://pubmed.ncbi.nlm.nih.gov/18359748/
Pretty sure the probability of making it to adulthood has never been below 50% excluding war, plague, or famine (which were common, so hard to normalize)
But if 50% reaches an average age of, say 2, assuming it’s right skewed for those who died before 10; then an average life expectancy of 50 for the remainder means the average life expectancy overall just 26. That squares with the numbers stated I suppose.
If you're going to do that then you might as well just use UUID, since you effectively reintroduce the negative aspects of that (infinitesimally miniscule chance of collisions, computation involved in the calculation, etc.)
The difference is that you can still use sequential IDs internally, while exposing hashed IDs to the outside. This protects your database from collisions under all circumstances, while in the absolute worst case, a single user might experience bugs because two external IDs collide.
This is a weird proposal. If you're using non-hashed IDs internally and exposing hashed IDs externally, you are going to need to map those (securely hashed) ids back to internal ids when the client hands them to you.
I guess you could do this with complete table scans, hashing the ids and looking for matches, but that would be horribly inefficient. You could maintain your own internal reverse index of hash -> id but now I have to ask what's the point? You aren't saving any storage and you're adding a lot of complexity.
Seems like if you want random unguessable external ids, you're always better off just generating them and using them as primary keys.
Also, you aren't protecting your database "from collisions under all circumstances" - there's no guarantee your hash won't collide even if the input is small.
Yes, it is more reasonable to use encrypted IDs externally from structured/sequential IDs internally, not hashed IDs. Recovering the internal ID from the external ID is computationally trivial since it will fit in a single AES block and you don't have to worry about collisions.
Yes, I tend to like this philosophy in database design, of internal sequential ids which are used for joins between tables etc. and an exposed "external reference". But I typically would use a UUID for my external reference rather than a hash of the internal id.
Doesn't that just add a whole lot of unnecessary complexity? If elements have multiple IDs, one of which should not be leaked to the outside, that's just asking for trouble in my opinion.
Is generating UUIDv4 or UUIDv7 really too much effort? I'd assume that writing the row to the database takes longer than generating the UUID.
It also means once your hash function leaks for whatever reason or gets brute forced because of whatever weird weakness in your system, it's game over and everybody will forever be able to predict any future ids, guess neighboring ids, etc., unless you're willing to change the hash and invalidate all links to any content on your site.
If I'm in a scenario where I think I need consecutive ids internally and random ones externally, I'll just have two fields in my tables.
Store just the sequential id, compute the hash on the edge.
This keeps your database simple and performant, and pushes complexity and work to the backend servers. This can be nice because developers are typically more at home at that layer, and scaling the backend can be a lot easier than scaling your database. But it also comes with the downsides listed in this thread.
Good point. Back when we did that we just used a reversible hash function (some would call it encryption). There are some simple algorithms meant for encrypting single integers with a reasonable key.
I might be misremembering, but didn't YouTube do this in the early days? So yeah, that was what I was thinking of when replying, not a traditional hash function.
