> 2. I still suggest to implement it in a way that leaves the door open
> to not have an oid for every table/tuple per default.
> 3. Tables without oid would simply not have all the OO functionality.
> tuples without the oid would not exist in the *OO world*
> 4. I think it is valuable to have both OO and fast relational stuff.
(ORDBMS)
>
How about supporting CREATE TABLE and CREATE CLASS?
CREATE table would give the features for the relational model (like no oid?)
while create class would provide identity, polymorphism, inheritance as
would be preferred in the OO world.
What do you think?
I'm also considering trying to store tuples for derived class in the same
file as the tuples for the base class. This might make it easier
to provide inheritance of triggers/indices etc.
This seems relatively easy to do if the class id of a tuple is stored in
the tuple, otherwise supporting inheritance of triggers etc seems like
it's going to be an expensive operation which will also be fundamentally
broken from an OO perspective. (specifically, more than one identity
for a single object).
What do you think? Is it "easy" to do?
Thanks,
Maurice