Re: Thus spoke SQL3 (on OO)

On Sun, 21 May 2000, Chris wrote:
> "Robert B. Easter" wrote:
>
> > SQL3 does not appear to really have an object model. Rather, it
> > appears to be a hierarchial model on top of the relational model.
>
> It seems like it amounts to the same thing to me. A bit like me saying
> "A circle is the set of points equi-distant from a point", and someone
> else arguing "No, a circle is the graph of points represented by the
> formula x^2 + y^2 = n". At the end of the day they amount to the same
> thing I think.

I guess the major difference is that the hierarchial-model does not support
multiple inheritance. Again it is basically a tree going from one parent
branch to many children branches where the children basically ARE the parent
table, just adding some more column leaves so to speak (adding nodes to a
tree, its still all one tree). Object-oriented allows both one parent to yield
many children and many parents to combine to yield a single child. The
instances are not dependent on each other, just the declarations are so that
you can delete a parent instance and it has no effect on a child since they are
not part of a data tree together. A tree generally never allows two branches to
merge into a single branch. Something like that. OO lets you do more
without the instances having to be part of a dependent data tree.

I was thinking that maybe this hierarchial model over relational-model in SQL3
(as I see it) was designed that way to allow easier transitions of legacy
hierarchy databases to the new SQL3 relational systems.

I'm no OO expert, and again I may have this ALL wrong! But, I don't see the
OO features of C++ being comparable to OO in databases all the time. C++
generally uses only the CLONES type of inheritance, is procedural, and
allows a derived class to be passed anywhere the parent might normally be
passed.

What follows is my attempt to compare C++ OO and database OO: In C++, a
function programmed to take a parent class as input, is only programmed to
use/access the attributes that parent has. If you pass a derived class, the
function still only uses the attributes that the parent has too. I think it is
abusing C++ if a function that takes a parent arg but is also aware of derived
classes in advance and does a test to see what is being passed. The idea of C++
inheritance was that you could make parent, and functions that use parent, then
later someday derive a child from parent that you never thought you'd need.
Then, the functions that work on parent still do their thing even on the child.
A function that is programmed for a parent class and that has advance knowledge
of some derived class is not good OOP. 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. The SQL declaration
"SELECT * FROM parent" is like the C++ function declaration "void
useparent(parent *p)". Both only know about parent objects in the definition
(what uses the data obtained). The definitions of what to do with the data
lies inside the client that issues the SQL declaration, and within the C++
function definition, respectively. Both should only be expected to understand
how to process what they declare. Sending back unpredictable numbers of and
types of columns might break the procedural/definition part that is outside
SQL's declaritive domain which is to precisely declare what data to get. I
think that single-type rows should still be returned from selects. Its the
relational way too, and the database still is a relational database. Returning
the additional child columns just seems to be a waste of processing and
bandwidth when selecting parent. C++ will just send a pointer, so there is no
penalty, but in the database, there is a speed penalty for sending those other
columns that the parent doesn't have.

Another, more difficult point about why not to send variable row types, has to
do with the ISA relationship in inheritance. Child ISA parent. Parent is not
necessarily a child. A child can be used anywhere a parent can be used. A
parent cannot be used anywhere a child can. 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. Say that mostly
child-type rows are returned by SELECT * FROM parent, only an occasional
parent-type actually comes through. A procedure might sample the input (or a
human might) and decide that the procedure should be different since it looks
like only child-type rows are returning. Then, when a parent-type appears, it
is processed wrong. Maybe this argument is weak. Comments? :-)

Robert B. Easter