6 ms·

UUIDs are very wasteful [1]. For most use cases you can replace them with much shorter strings and still have very low chances of collisions [2] [1] https://he

UUIDs are very wasteful [1]. For most use cases you can replace them with much shorter strings and still have very low chances of collisions [2] [1] https://henvic.dev/posts/uuid/ https://henvic.dev/posts/uuid/ [2] https://alex7kom.github.io/nano-nanoid-cc/ https://alex7kom.github.io/nano-nanoid-cc/

PittleyDunkin 2y ago
Sure, at cost of increased complexity of access. Sometimes the waste is worth the simplicity.
cogman10 2y ago
Call me crazy, but I'm simply splitting my UUID into the higher and lower bits and indexing off that. IE CREATE TABLE foo( id_ms UNSIGNED BIG INT NOT NULL, id_ls UNSIGNED BIG INT NOT NULL, PRIMARY KEY (id_ms, id_ls) ) WITHOUT ROWID; That works well with UUIDv7 and is just storing 128bits rather than a full string. In most languages it's pretty trivial to turn 2 longs into a UUID and vice versa.
- diroussel 2y ago
  Is there any advantage to this approach over Postgres native uuid support which should store the same number of bits?
  - cogman10 2y ago
    No. This approach is strictly for DBS like sqlite without uuid or 128bit integer support.
dymk 2y ago
Sounds complex, just use a UUID. If that’s the dominating factor for storage, then you have a different problem to solve.