Chris Bitmead wrote:
>
> "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...
Chris, what is your position on having a single primary key for all
inherited columns ?
It seems right for single inheritance (tree-like), but generally
impossible for multiple inheritance, unless we will allow multiple
"primary" keys (which we could allow anyhow, as they seem useful even in
several non-OO situations). For purity we could set the syntax to be
ALTERNATE KEY or ALTERNATE PRIMARY KEY, but they would really be
still primary keys ;)
> > 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.
For more dynamic client languages you could even first ask each object
to enumerate methods it knows about and then perhaps make a separate
menu
(combobox) from them for client to choose from for each instance.
------------
Hannu
