Hannu Krosing wrote:
> 2. a way to go from OID to tuple
>
> The must efficient solution seems to be a file with a simple structure
> that
> has records of (TUPLE_OID,TABLE_OID) wher a record is added at each
> insert.
> As this file is ordered wrt. TULE_OID and has fixed size records, it can
> be efficiently searche with binary search. As it is append-only it is also
> quite (probably most) efficient on inserts. I can't think of any solutions
> using current structures which would be nearly as efficient.
If you have your suggested indexes that apply over multiple relations, I
can't
see why that can't be used for this too. It just means that if you use
ODBMS it
is recommended that you do a CREATE INDEX oid_idx ON object (oid), where
"object"
is a conceptual super-class of all other objects.
Your append-only file would grow without limit, which I think is a bit
of a
problem for some apps. Also the way ODBMS will work is an application
will
ask for a chunk
of oids from the database, some of which may be later "wasted".(This is
how
Versant works and it is also a technique documented by Stonebraker in
his
postgres papers). This technique is so that applications don't have to
talk to the backend to create objects in the front end that need oids.
This means objects may not be created with oids in order.
So you have to store space for oids in your file that may not be used.
I think we need first more conventional style index that works well.
Then we
can experiment with more radical ideas.
> The same kind of file could be used for re_introducing time-travel in an
> efficient way.
How?
> 5. become even more object-oriented and add methods to tables that can do
> different things depending on which table they operate on.
Does this definitely not work now?