Re: Thus spoke SQL3 (on OO)

"Robert B. Easter" wrote:

> I guess the major difference is that the hierarchial-model does not
> support multiple inheritance.

I don't agree. From SQL3...

"To avoid name clashes, a subtype can rename selected components of the
representation inherited from its direct supertypes."

and if that doesn't clinch it...

"Let the term replicated column mean a column appearing in more than one
direct supertable of T that is inherited by at least one of those direct
supertables from the same column of a single higher-level supertable."

That sounds like multiple repeated inheritance to me.

> Passing different row types to the
> client from one select, forces that client to be like the C++ function
> programmed in advance to deal with some derived class too.

You are assuming that the client application will be responsible for
dealing with these differences. What really happens is that a query is
more like a List<Baseclass> in C++. As long as you only call methods
contained in Baseclass on each element of the List, you are ok.

But those "virtual" methods you call need real objects to work with.
They need ALL the attributes in other words. The piece of language
infrastructure that behind the scenes instantiates all the C++ objects
as they fall out of the database can't create abstract Baseclass
objects. It needs all the attributes to instantiate Subclass objects, so
that the application code needn't know about different classes.

I suggest you download an evaluation copy of an ODBMS and have a play,
it will probably become clear.

> By sending the differing row
> types, the procedure that processes the rows might end up expecting child rows
> more than parent rows, even though you are using SELECT * FROM parent. The
> different rows are processed differently. If programmers become accoustomed
> to obtaining the child-type rows by selecting parent, they might eventually
> mistake a parent to be ISA child when one is received.

Whether a programmer is likely to make such a mistake depends more on
the programming language used. In an ODBMS situation almost all object
retrievals are not via an explicit query, but rather by object
navigation. You might have

class Purchase {
Link<Customer> buyer;
List<StockItem> items;
}

Result<Purchase> r = Query<Purchase>::select("select * from purchase");
Iterator<Purchase> i = r.iterator();
while (i.hasNext()) {
Purchase *p = i.next();
Customer *c = p.buyer;
Iterator<StockItem> = p.items.iterator();
// etc.
}

Any one of Purchase, Customer or StockItem might really be some
sub-class of those classes for all the application knows. But the behind
the scenes infrastructure needs to have all the attributes so that the
application code need not know.