5 ms·

What drives me nuts is people storing uuids in databases as hex strings. They're bytes, and if you do it right, even the type 1's are lexigraphically sortable.

Kwpolska 2y ago
Hex strings may require more storage, but they remove the need to convert back and forth and make it easier to manually query the database when debugging. The best type is your database's uuid type if it has one.
- zarzavat 2y ago
  There’s no reason to use hex though. Base32/36/62/64 should be considered.
  - willvarfar 2y ago
    there's no reason to not use hex, though. In my post this is replying to, I mentioned "in lots of databases you can do some sql like TIMESTAMP_MILLIS(CAST(CONCAT("0x", LEFT(REPLACE(id, '-', ''), 12)) AS INT64)). This is a massive advantage over systems that use non-hex encodings." I've had struggles with binary and base62 encodings and things and just want everyone to use hex. Typical databases compress rows or columns anyway these days; or if they don't, then the storage does. So often the question is entropy not character count. For example storage I work with these days takes as an identical number of bytes to store a hex string as to store the same id as a byte array.
    - cbsmith 2y ago
      > Typical databases compress rows or columns anyway these days; or if they don't, then the storage does. So often the question is entropy not character count. For example storage I work with these days takes as an identical number of bytes to store a hex string as to store the same id as a byte array.mo Storage tends to be cheap, so it's less about that, and more about memory consumption and index efficiency. The cost of transforming back to and from binary is also pretty trivial on modern systems.
- cbsmith 2y ago
  Stuff gets "converted" between you and the database anyway. If you really want to see it as though they were strings all the time, you can always make a view.

Kwpolska 2y ago

Hex strings may require more storage, but they remove the need to convert back and forth and make it easier to manually query the database when debugging. The best type is your database's uuid type if it has one.

zarzavat 2y ago
There’s no reason to use hex though. Base32/36/62/64 should be considered.
- willvarfar 2y ago
  there's no reason to not use hex, though. In my post this is replying to, I mentioned "in lots of databases you can do some sql like TIMESTAMP_MILLIS(CAST(CONCAT("0x", LEFT(REPLACE(id, '-', ''), 12)) AS INT64)). This is a massive advantage over systems that use non-hex encodings." I've had struggles with binary and base62 encodings and things and just want everyone to use hex. Typical databases compress rows or columns anyway these days; or if they don't, then the storage does. So often the question is entropy not character count. For example storage I work with these days takes as an identical number of bytes to store a hex string as to store the same id as a byte array.
  - cbsmith 2y ago
    > Typical databases compress rows or columns anyway these days; or if they don't, then the storage does. So often the question is entropy not character count. For example storage I work with these days takes as an identical number of bytes to store a hex string as to store the same id as a byte array.mo Storage tends to be cheap, so it's less about that, and more about memory consumption and index efficiency. The cost of transforming back to and from binary is also pretty trivial on modern systems.
cbsmith 2y ago
Stuff gets "converted" between you and the database anyway. If you really want to see it as though they were strings all the time, you can always make a view.