Sugi,

Personally, I'd suggest that you use GUID values instead of generators.

The advantage of this approach is that you can determine the key value
without any database operation and thus are ideal for the management of
master/detail data. The nature of a GUID is such that it is 99.999999%
guaranteed to be unique for all PC's.

One disadvantage is that the key is long and sometimes hard to read,
which can make debugging and hand-built queries at bit of a bother.


Sean

> -----Original Message-----
> From: slim@... [mailto:slim@...]
> Sent: Monday, October 01, 2001 3:42 PM
> To: ib-support@yahoogroups.com
> Subject: [ib-support] Re: Generator Limits and How to Cope
>
>
> Dear All,
>
> > it's 68 years.
> > 32 bit signed is 2.17 Billions in the positive range.
> > One day has 86400 seconds, so an average year has 365.25 * 86400
> > seconds.
> >
> > 2.17 * 10^9 / 86400 / 365.25 =~ 68 (years)
> Ahh... So that's why these issue never came up in any discussions so
> far....:) OK, to re-iterate, basically we are safe, even when putting
> cancelled postings into the picture. If that's the case then most of
> the issues I raised earlier are irrelevant ('garbage collection',
> etc). My earliest calculations showed that, for the worst case, I was
> safe for around 10 years before this decision will come back to haunt
> me...:)
>
> But no one commented on my second question; about master-detail
> generator PKs. What is the best way to implement the detail PK? As of
> now we have several possibilities:
> 1. Client-side manual increments (using code).
> 2. Server-side manual increments (using triggers).
> 3. Server-side generator increments (using one generator for the
> whole detail table).
>
> Alternative #1 and #2 require coding in the triggers to generate the
> detail_ids, which can be a bit ugly to maintain, but not too much of
> a problem. Alternative #3 is attractive because it's the simplest one
> to implement, but I think it will catch the limit much faster than
> the single table PKs. (Assuming 5 details per master on average).
>
> Thanks for taking the time to reply,
> Salam,
> sugi.