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.