5 ms·
Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical ID
by jszymborski 1y ago
Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?
With HMAC, you can still ask for some sequential IDs
SipHash128(0, KEY) = k_0
SipHash128(1, KEY) = k_1
You get the same number of bits as a UUID.
You can't, however, sort by IDs to get their insertion sequence, however. For that you'd need something like symmetric encryption but this is already a bad idea, no reason to make it worse.
- hardwaresofton 1y agoYou could also "just" have an internal-use only numeric ID, or use a UUIDv7.
- sam_lowry_ 1y agoor ULIDs or any other partially sortable ids.
- sebazzz 1y agoULID are not necessarily sortable, just UUIDs consensed in a shorter string by using more characters than 0-9A-F
- sam_lowry_ 1y agoULID = Unique Lexicographically sortable IDentifier ;-)
- jszymborski 1y agoULIDs are sorta the opposite of the HMAC method, where you can't query for the nth ID, but you can sort the IDs.
- redhale 1y agoTIL about UUIDv7 -- thanks!
- hardwaresofton 1y agoNo worries! It's just now finally starting to get everywhere -- Postgres is going to get it in 18 by the looks of things :) https://www.postgresql.org/docs/18/functions-uuid.html https://www.postgresql.org/docs/18/functions-uuid.html