Is there any value in UUID over a 64bit numeric format like Twitter Snowflake? If so, is there any value in UUID over extending Twitter Snowflake to a 128 bit numeric format?
I am confused why it’s not more common to roll your own own surrogate key identifier numbers to match an application’s particular use case, desired sort order, desired partition method, desired cryptographic randomness, etc.
I think rolling your own is plenty common. It doesn’t seem too troublesome to do. The big reason to pack your custom ID into a UUID is interoperability. They’re easily recognizable in plaintext formats and natively supported by a plethora of databases and serialization format with a semantic ID type. I think many people start with normal UUID these days, and then “upgrade” to a home grown semantic UUID once the need arises. New formats the codify standard practice are nice.
This is pretty good, but an editor needs to go through and s/utilize/use/ about a hundred times. (What’s that about?)
If reading this draft makes you think of ways it could be improved, see the instructions for contributing at https://github.com/uuid6/uuid6-ietf-draft#contributing.
Is there any value in UUID over a 64bit numeric format like Twitter Snowflake? If so, is there any value in UUID over extending Twitter Snowflake to a 128 bit numeric format?
I am confused why it’s not more common to roll your own own surrogate key identifier numbers to match an application’s particular use case, desired sort order, desired partition method, desired cryptographic randomness, etc.
I think rolling your own is plenty common. It doesn’t seem too troublesome to do. The big reason to pack your custom ID into a UUID is interoperability. They’re easily recognizable in plaintext formats and natively supported by a plethora of databases and serialization format with a semantic ID type. I think many people start with normal UUID these days, and then “upgrade” to a home grown semantic UUID once the need arises. New formats the codify standard practice are nice.