NetTalk Central

Author Topic: GUID Question  (Read 522 times)

rupertvz

  • Sr. Member
  • ****
  • Posts: 319
    • View Profile
    • Email
GUID Question
« on: May 24, 2024, 02:54:50 AM »
Hi Guys,

All my GUID's are 16 characters, and relations between my tables are all GUID based lately.

A .Net developer told me that the GUID should ideally be 32 characters.

Does this mean moving forward it is best to cater for 32 bit GUID's in my tables, or will 16 characters suffice for the foreseeable future.

I did a bit of reading up on this, but would like to hear any comments.

rjolda

  • Sr. Member
  • ****
  • Posts: 290
    • View Profile
    • Email
Re: GUID Question
« Reply #1 on: May 24, 2024, 04:18:38 AM »
Hi,
16 characters - each can have up to 36 choices ( Upper case alphabet) gives you 2.2300745198530623141535718272648e+43  unique values.  Do you need more than that?
If you do, then you can go to 32 characters and you will get 1.5324955408658888583583470271503e+54  values.  You can choose.  Bruce recommends 16 characters but you can zone in on your own comfort zone!
Ron

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11204
    • View Profile
Re: GUID Question
« Reply #2 on: May 27, 2024, 08:51:54 PM »
>> A .Net developer told me that the GUID should ideally be 32 characters.

He's likely referring to the UID version 4 format.
https://en.wikipedia.org/wiki/Universally_unique_identifier
which is a 16 byte string (but often represented as 32 hex digits, with some colons.) (16 character alphabet, 0-9 and a-f)
These have about 121 bits of randomness (aka "entropy")

The Guids we tend to use in Clarion are also 16 chars long, but because it's easier to deal with text values, the alphabet is restricted to 36 characters (0-9 and A-Z). This results in approximately 83 bits of entropy.

So yes, a UIDv4 has more bits of entropy, and can hold more values than the Guid you are using. However it is harder to deal with as it can contain binary values, so needs to continually be encoded and decoded when moving to a text form.

The risk of a collision is n / 2^82 where n is the number of records in your table. (Not in the database, in the table.) If you feel that this value rises to unacceptably high levels then you can increase the length of the string, or the size of the alphabet. I would suggest this is a useful thing to do when you are expecting around 4 835 703 278 458 516 698 records - at which point the risk of a collision would be about 1 in a million.