At 07:30 PM 11/9/2001 +0000, zifnabbe@... wrote:

> > > 2. Slower than using an INT64 key.
> >
> > Not, really once the value has been calculated but does depend on
>the datatype used to store the GUID value (CHAR(36) vs. CHAR(26) vs.
>OCTET).
>
>Can you tell me more on this? Is this because the database isn't
>optimized for chars?

The database handles char fields just fine. The issues are in the
index handling. I'd certainly declare a GUID to be a charset OCTET
because the index code assumes that trailing blanks are not significant -
where as the trailing 0x20 is significant. The second issue is
compression. An identifier based on a generator is eight bytes long,
and prefix compression works quite well, with an average stored key
length of less than 2 bytes. The GUID starts at 36 bytes and, depending
on the algorithm used, may not be compressible. The GUID algorithm
that I am familiar with changes the first byte for each new id,
greatly reducing the effect of prefix compression. Less compression ->
longer keys -> fewer keys per page -> deeper indexes -> worse performance.




Regards,

Ann
www.ibphoenix.com
We have answers.