That’s surprising to hear. I have zero DB experience, not am I a developer, and my default assumption is that some UUID maps to object / entry containing email address (and all other attributes).
Natural primary keys (email, ssns, etc) was the standard for a long time. It was some kind of platonic ideal. Artificial keys were wasted space of random data that didn’t belong in a database.
When I was in college, academics were just starting to grudgingly accept artificial primary keys (like UUID or auto-incrementing integers) as a concession to reality.
To a modern developer natural primary keys sound insane. Artificial keys are faster in almost every way due to index size. You’re storing compact, fixed-size binary data instead of strings.
I’ve been professionally making database since 1997 and “natural” primary keys was an antipattern even back then (along with the int sequence since it only allowed 2 or 4 billion).
Socials change. Emails change. Seemingly natural, unchanging things change and mess up all the foreign key relationships.
You see it a lot with Java devs or others who think in OOP objects and then try to simply push those to a table. That said it’s a little more rare now, since most ORMs helpfully auto-creates PKs for you as an int or uuid.
kayodelycaon|2 years ago
When I was in college, academics were just starting to grudgingly accept artificial primary keys (like UUID or auto-incrementing integers) as a concession to reality.
To a modern developer natural primary keys sound insane. Artificial keys are faster in almost every way due to index size. You’re storing compact, fixed-size binary data instead of strings.
prepend|2 years ago
Socials change. Emails change. Seemingly natural, unchanging things change and mess up all the foreign key relationships.
liquidpele|2 years ago