Zeugswetter Andreas SB SD wrote:
>
> > It seems to me, I guess and others too, that the OID mechanism should
> be on a
> > per table basis. That way OIDs are much more likely to be unique, and
> TRUNCATE
> > on a table should reset it's OID counter to zero.
>
> Seems to me, that this would be no different than a performance improved
> version
> of SERIAL.
> If you really need OID, you imho want the systemid tableid tupleid
> combo.
> A lot of people seem to use OID, when they really could use XTID. That
> is
> what I wanted to say.
>
I don't care about having an OID or ROWID, I care that there is a 2^32 limit to
the current OID strategy and that a quick fix of allowing tables to exist
without OIDs may break some existing software. I was suggesting the OIDs be
managed on a "per table" basis as a better solution.
In reality, a 32 bit OID, even isolated per table, may be too small. Databases
are getting HUGE. 40G disk drives are less than $100 bucks, in a few months 80G
drives will be less than $200, one can put together 200G RAID systems for about
$1000, a terabyte for about $5000. A database that would have needed an
enterprise level system, just 7 years ago, can be run on a $500 desktop today.
--
5-4-3-2-1 Thunderbirds are GO!
------------------------
http://www.mohawksoft.com