>>>>Hi,
>>>>
>>>>>The 16 byte GUID can be easily derived from an API call (I saw how VFE does it - and so can probably other frameworks, and there may be code elsewhere too), which IMO means that instead of doing a whole day or more of research, we can take ten minutes to implement one of the existing solutions.
>>>>
>>>>This is one of the major reason I started this thread. I am using Promatrix for a project I am curretly working on. The framework provides a very easy way to create surrogated key in GUID of 16, 22, 23, 26, 32, 36, 38, 48 or 128 characters. The recommanded one to use is GUID of 23 chars... I just want to see, beside performace, what else can be a factor in choosing the length. IMHO, space saving is relatively less important since storage cost is really cheap nowadays. And I think you have raised a good point to consider, I mean the easiness in getting it a GO!
>>>
>>>16 bytes = 128 bits. Everything else is just a derivative of the original 16 bytes. There is no need or benefit to storing the derivatives.
>>
>>The benefit would be a human readable form... which is sort of nonsensical in a meaningless key. So I really wouldn't bother.
>
>You could always convert to a human readable form as required.
>
>>
>>Though, these 16 bytes, if VFE is any guide, are actually hex representation, therefore 64 bits
>
>Pardon? 16 bytes * 8 bits = 128 bits, not 64 ;)

Hex, I said. Hex representation (an arguably human-readable form) takes two bytes for one actual byte of content.

There's a difference between displaying a field of 8 bytes as 16 hex digits, and actually storing these 16 digits as a string - then they do take 16 bytes.