### re: What would you use as a sortable, globally unique, ID? VIEW POST

re: Why not use two fields, a UUID and a timestamp?

I like the lateral thinking going on in your question :)

That's the status quo though, which works decently but it still requires two fields.

What if you could look at two IDs and roughly know which one comes first? What if the IDs carried with them both info? The timing and the uniqueness...

Hehe. Then what about the brute force approach, concatenation of timestamp and UUID, using an intermediate character guaranteed not to occur in one of them?

Edit: lexical and chronological sorting of ISO8601 date times is identical. So if you start with that, then the UUID, does that solve the problem?

Then what about the brute force approach, concatenation of timestamp and UUID, using an intermediate character guaranteed not to occur in one of them?

Something like this could work :)

You're really close to the solutions I found searching on the internet, take a look at github.com/segmentio/ksuid for example

You would have to perform more complex comparisons to see if ids match, since you lose the binary representation. v1 and v1mc UUIDs are sort of ordered but not necessarily between multiple nodes, and they cycle fairly rapidly.

Jimmy Nilsson did an interesting experiment back in the day with adding the timestamp inside the UUID itself.

First: it's a little bit funny to read an almost 20 years old article that talks about RAM in order of megabytes :D

I love how hacky his solution was, though it's a little bit weird that the timestamp is at the end, but that's just the order of the two casts.

This part was funny as well:

A DATETIME has the "precision" of 1/300th of a second, and it's no problem for SQL Server to generate five GUIDs in 3ms with this algorithm

5 IDs in 3 ms. Oh, the year 2000 :D

As an aside I wonder how slower the uuid type in PostgreSQL is in comparison to integer primary keys, today.
When you said "intermediate character" I took it to mean a string 1567876931|11aca736-c9a9-4266-a2f6-13bd07202c09 or some such.