3 ms·

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

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.

deleted 8y ago
[deleted]
grzm 8y ago
> "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-is-on-our-side 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.
zzzcpan 8y ago
> 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.
mitchtbaum 8y ago
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 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-slugid-vs-short-uuid-vs-ksuid https://www.npmtrends.com/nanoid-vs-shortid-vs-cuid-vs-slugi... (Found through: https://github.com/grantcarthew/awesome-unique-id https://github.com/grantcarthew/awesome-unique-id)

deleted 8y ago

[deleted]

grzm 8y ago

> "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-is-on-our-side 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.

zzzcpan 8y ago

> 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.

mitchtbaum 8y ago

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 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-slugid-vs-short-uuid-vs-ksuid https://www.npmtrends.com/nanoid-vs-shortid-vs-cuid-vs-slugi... (Found through: https://github.com/grantcarthew/awesome-unique-id https://github.com/grantcarthew/awesome-unique-id)