News for hackers. Stuff that matters.
Re:You'll regret using natural keys by WorldMaker on Wednesday June 05, 2024 @01:35PM (#40587875)
A different approach to solve both 1 and 2 is timestamp-oriented IDs. You can get useful cache locality/less "index bloat"/fast initial inserts if your keys can be easily ordered in time. Sorted by timestamp means very similar behavior to B-Tree appends of a monotonic integer, even sometimes in the worst cases where "same moment" IDs aren't monotonic and rely more on random entropy.

I got some great DB cache/index performance from ULIDs with a bit of work to order the ULID timestamp bits in the way the DB's 128-bit column "uuid" sort best supported.

Now that UUIDv7 is standardized we should hopefully see good out-of-the-box collation for UUIDv7 in databases sooner rather than later.

Re:You'll regret using natural keys by reissbaker on Thursday June 06, 2024 @04:08AM (#40594829)
Yep, that works too as long as the timestamp data isn't sensitive.