--- In firebird-support@yahoogroups.com, Ann Harrison wrote: > > On Mon, Jan 28, 2013 at 2:21 PM, Jeff wrote: > > > > > > > High/Low is a technique of generating primary keys client side in contrast > > to generating keys server side with fb generators. Here is a link to a > > discussion that probably could explain it better: > > http://stackoverflow.com/questions/282099/whats-the-hi-lo-algorithm > > > > The application I am trying to build is distributed system spread > > geographically, most of them on slow connection. Hence, the need for client > > side generated primary keys. > > > I guess I don't quite follow that logic. One low-to-no cost option is to > generate your keys on server using an INSERT ... RETURNING to get the value > back, if that's supported through your interface. >
My own humble experience suggests that INSERT ... RETURNING is great for client-server apps, not for distributed apps, although it could be my mangled code and logic that is at fault here. Oh, BTW, RETURNING is not available for fb 1.5. > > Basically the High/Low key scheme appears to be a two-part primary key > where the first part is obtained from the database, probably from a > generator, and the second part is incremented in the client. Assuming it's > handled to avoid the confusion between 13/23 and 132/3, that should be OK. > As long as each client is adding values in approximately the same part of > the index, the performance should be fine, especially if you're expecting > no more than a million records in three years. Index load performance gets > much more interesting when you expect millions of records a week. > > > > Having the most variable part of a key last leads to better index > compression. > > > > More work though, and an integer data type might not suffice to accomodate > > the now very large value PK. Maybe should use Numeric(18,0)? > > > > Or - forgive me I work with several databases and sometimes forget what > 64-bit integers are called in each - use a BigInt. > > > > > OTOH, if you say these are non issue with fb, then maybe I should just > > consider GUIDs or UUIDs for PKs and forget about the server altogether with > > regards to PK generation? > > > > GUIDs and UUIDs are normally generated in a way that defeats prefix > compression. > > > Good Luck, > > Ann > > > > > > [Non-text portions of this message have been removed] >
