5 ms·
Assuming the alternative is a fully random key, this can wreak havoc for performance depending on the database engine and index type used (lots written on this
by parhamn 3y ago
Assuming the alternative is a fully random key, this can wreak havoc for performance depending on the database engine and index type used (lots written on this topic).
But I do agree, if performance isn't an issue with your db choice and you're not interested in in getting a free "created_at", might as well go fully random.
- hot_gril 3y agoPrimary keys have to be chosen carefully because they impact disk layout, joins, etc, and full random makes bad PKs in certain distributed DBs. But it's simple and cheap to convert a public user ID (full random) to/from internal row keys (sequential-ish) at the API boundaries using a secondary index or even a cache.
- hot_gril 3y ago(Like, simple/cheap enough that it's probably worth doing instead of exposing your row keys. Maybe in some careful cases exposing uuid7 row keys makes sense, but not nearly enough to recommend that so broadly. It's not a safe default.)
- parhamn 3y agoMakes sense. Longest HN convo I've managed to keep at this point -- thanks for engaging!