Subject | Re: [ib-support] String Key-Field? |
---|---|
Author | Guillermo Najar-Arreola |
Post date | 2002-08-29T21:49:42Z |
Thank you Ann
""Ann W. Harrison"" <aharrison@...> wrote in message
news:5.1.0.14.2.20020829161503.04413db0@......
""Ann W. Harrison"" <aharrison@...> wrote in message
news:5.1.0.14.2.20020829161503.04413db0@......
> At 02:03 PM 8/29/2002 -0500, Guillermo Najar-Arreola wrote:a
> >Hi,
> >
> >I found that GUID is a beautiful candidate for OID; the point is that its
> >string. How much I loose in performance if I use a string primary-key
> >instead of a numeric one for ALL my tables ? Of course, if the PK will be
> >string, FKs shall be too.
>
> Probably not perceptible, depending on the compression. Different GUID
> representations are configured differently. For best compression, put
> the least variable part first and the most variable part last. For
> example, if the GUID consists of eight bytes of local key, eight bytes
> of machine identifier, two bytes of sector of universe, two bytes of
> galaxy, four bytes of solar system, two bytes of planet, and four bytes
> of manufacturer, you should build the key in this order:
>
> universe, galaxy, solar system, planet, manufacturer, machine, local
>
> The first six sections will be compressed to oblivion, so the average
> key length will be about 8 bytes.
>
> The difference in performance between key types has nothing to do with
> data type and much to do with average key length.
>
> If you reverse the order, so the key starts with the local value,
> the average key length will be something like 30 bytes, so the index
> will be nearly 4 times as big.
>
> Regards,
>
> Ann
> www.ibphoenix.com
> We have answers.
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>