Hacker News Reader

Comment by prepend | Hacker News Reader

I think this is a backend issue in that for the user, their id is email, but within the systems’s data the primary key shouldn’t be email.

Is anyone still doing this? It’s like the most basic db design issue to not use things like email as the identifier and instead have a lookup table that maps things to a truly unique id (uuid or maybe auto increment from a sequence).

The article doesn’t really make this distinction so it almost reads like how users should be aware of this abstraction.

View on HN

Yea… this is like a high school level DB class test problem, but you’d be surprised how many adult developers don’t stop to think about DB stuff…

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.

Reply on news.ycombinator.com