Be Careful with UUID or GUID as Primary Keys

Re:Be Careful with UUID or GUID as Primary Keys by ivan_gammel on Friday June 09, 2017 @03:55PM (#14523992)

Well, that's possible, but I'd say it's generally better to keep close to the spec and v4 is the closest option here.

[ Parent | on HN ]

Re:Be Careful with UUID or GUID as Primary Keys by MichaelGG on Friday June 09, 2017 @03:59PM (#14524026)

But what's the value in the "spec" here? I see people mentioning this and I'm wondering what the rationale is.

[ Parent | on HN ]

Re:Be Careful with UUID or GUID as Primary Keys by cronjobber on Saturday June 10, 2017 @02:58AM (#14526433)

The rationale is that you can use them along with those other versions of UUID that contain nonrandom data.

Assume Bob uses one such not-entirely-random UUID variety and actually makes use of the embedded information. Charlie uses random UUID. Bob and Charlie merge their data.

If Charlie had filled the version bits with random garbage, the merge would poison Bob's use of the embedded information.

Basically, UUIDs are a discriminated union type.

[ Parent | on HN ]

Re:Be Careful with UUID or GUID as Primary Keys by ivan_gammel on Saturday June 10, 2017 @03:57AM (#14526540)

Thanks, that's the best answer.

[ Parent | on HN ]

Re:Be Careful with UUID or GUID as Primary Keys by concede_pluto on Saturday June 10, 2017 @10:26PM (#14530299)

By violating the spec you're assuming you'll never want to use a tool that strictly adheres to the spec. Postel's Law works best because it accommodates some people not following it.

[ Parent | on HN ]