Hacker News new | past | comments | ask | show | jobs | submit login

I don't understand the desire to store timestamp information into a UUID. Why not just add an extra timestamp field to your data? That seems like such a simpler solution then embedding it into your UUID. I would go further and argue that embedding anything but randomness into your UUID is a bad idea that you will pay for in the future.



> "I don't understand the desire to store timestamp information into a UUID"

One reason is to be able provide sortability with respect to what is often a surrogate key attribute, as listed in the introduction:

> "It borrows core ideas from the ubiquitous UUID standard, adding time-based ordering and more friendly representation formats."

You can find additional motivations in the "Time is on our side" section:

https://segment.com/blog/a-brief-history-of-the-uuid/#time-i...

> "In Cassandra, TimeUUIDs are sortable by timestamp, quite useful when needing to roughly order by time."

While you may not agree with the the reasons, I think they are understandable.


> embedding anything but randomness into your UUID is a bad idea that you will pay for in the future

It's not that simple. Depending on your case there could be plenty of reasons to avoid randomness altogether. Randomness doesn't guarantee uniqueness within the system, randomness is slow, randomness gives you false sense of security that you could accidentally rely on, etc.


Very well said.

In looking for an id scheme that focuses on unpredictability and readability, rather than on encoding metadata and sortability, I feel I've finally found what will work well: https://github.com/ai/nanoid

And others seem to agree (though unimportantly on a different platform): https://www.npmtrends.com/nanoid-vs-shortid-vs-cuid-vs-slugi...

(Found through: https://github.com/grantcarthew/awesome-unique-id)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: