How to store a GUID in a Progress database ?

[KrisM]

Suppose I want to use GUID's (or UUID's) as primary index for a new database table.
The GENERATE-UUID function returns a raw type value so my database column would be data type raw, if it were not that raw data type cannot be indexed.
I could use base64-encode to convert my GUID to a string but I wonder if somebody knows a better solution.

 

[Cecil]

I use the GENERATE-UUID for my primary key on my tables and I found using HEX-ENCODE(GENERATE-UUID) works quite well.

 

[Stefan]

Dragging up an old thread. Is character still the preferred data type for storing a uuid?

Pro: easy, visible and a single field
Con: spending 256 bits to store 128 bits.

Since a uuid is 128 bits it could also be stored as a pair of int64s.

Pro: 128 bits used to store 128 bits.
Con: you repeatedly need two fields for joining

 

[Rob Fitzpatrick]

Dragging up an old thread. Is character still the preferred data type for storing a uuid?

Pro: easy, visible and a single field
Con: spending 256 bits to store 128 bits.

Since a uuid is 128 bits it could also be stored as a pair of int64s.

Pro: 128 bits used to store 128 bits.
Con: you repeatedly need two fields for joining

Until PSC adds a native GUID type (not holding my breath), I'd use character, for code that is easier to read and data that is more meaningful during debugging, across a range of developer skill levels.

If we're talking about disk storage, the math can be a bit murky. A character field will be 33 bytes on disk; one-byte field length plus 32 bytes of data. Int64s are variable-size, depending on the values; I'm not sure what the distribution of values would be for halves of a UUID. But there will be two one-byte field length fields rather than one.

For me, clarity wins over incremental efficiency gains. Also, memory and disk aren't as expensive as they used to be.

Going back to the OP's requirement, I'm not sure why you would want a GUID as a primary key, unless you want to randomize record order?

 

[Stefan]

Going back to the OP's requirement, I'm not sure why you would want a GUID as a primary key, unless you want to randomize record order?

Not sure what OP's requirement was, but in a world filled with guids identifying objects, it makes sense to use the identifier as a key.

For example, the SAML claim from Azure Active Directory will only provide the groups a user is a member of as guids (when not backed by a synched n on-premise AD).