I have done a similar thing but since I do not like compound PKs, I assign a
certain range to each laptop or site or whatever and use a generator that is
never incremented. My PK triggers become something like this:

OID=GEN_ID(gen_machinenum,0)+GEN_ID(gen_oid,1);

this works for me 'cause there are more integers than I could ever use in
any given table. Each machine has a gen_machinenum that is assigned a
certain value, usually 0 for the "home" or "master" database and 10000,
20000, 30000 for each additional laptop (or site).


I'm not sure about the performance issues that Anne has addressed, I'd like
to know what she has to say about how this method compares

HTH

rob

----- Original Message -----
From: "Ann W. Harrison" <aharrison@...>
To: <ib-support@yahoogroups.com>; <ib-support@yahoogroups.com>
Sent: Wednesday, August 28, 2002 2:02 PM
Subject: Re: [ib-support] OID: Double or String?


> At 03:22 PM 8/28/2002 -0500, Guillermo Najar-Arreola wrote:
>
> >I'm planning how am I going to implement OIDs for any of my apps using
> >Firebird. I was thinking on strings since I have customers with laptops
that
> >download their information to a central server and I want to prefix the
OID
> >comming from each computer so I don't have conflicts with OIDs generated
in
> >the central server. For Interbase, what data type is more efficient for
> >primary keys ? double or string?
>
> Object identifiers can be implemented in several ways. The best, in my
> opinion, is to create a compound key. The first part of the key is the
> computer id, something that you assign and store in an integer field. The
> second part of the key is a value created by gen-id on each system and
> stored in an eight byte integer field. Because Firebird uses prefix
> compression on indexes, the initial "computer id" part of the key will
> almost never be stored and will have no measurable effect on index size.
>
> Eight byte integer - aka numeric (18,0) - is the best choice for an index
> key type in general because it's precise and dense. Firebird manipulates
> the keys it receives so they can be compared bytewise - inverting bytes
> and performing unnatural acts on floating point numbers. The stored key
> has both prefix compression and suffix compression. Suffix compression
> is applied to each part of a compound key. As a result, the stored key
> values vary in size...
>
>
> 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/
>
>