Re: OOP real life example (was Re: Why is MySQL more chosen - Mailing list pgsql-hackers

On 12 Aug 2002, Hannu Krosing wrote:

> Are you saying that inheritance in SQL is something fundamentally
> different than inheritance in OO languages ?

Yes.

> > (For example, the distinction
> > between types and instances of types is critical in OO theory. What are
> > the TI equivalants of this?)
>
> If by TI you mean type instance....

Sorry, I shouldn't have abbreviated this. By "TI" I meant "table
inheritance."

> then the equivalent of of an instance is
> a relation (i.e. one row in an (inherited) table).

As I understand it, one row in a table, inherited or not, is a
tuple, not a relation. The definitions I'm familar with are Date's:
a relation is a header, describing the types of attributes within
the tuple, and a set of tuples conforming to that header, and a
relvar is a variable that holds such a relation. (His definitions
seem to be the ones in common use--Korth/Silberschatz agree with
him, though they don't use the relvar concept AFIK.)

So is an instance a relation (a set of tuples) or a tuple?

If the former, consider the following argument.

In an object oriented program I can have a class C, and a subclass C'
that inherits from C. Now, in any situation that calls for an instance
of C, I can instead use an instance of C'. This is polymorphism.

Now, if an instance is equivalant to tuple, and a relation inherits from
another relation, I'd guess that a relation is equivalant to a class.
But given relation R' inheriting from relation R, does that mean that I
can use a tuple from R' anywhere I could use a tuple from R? No, obviously
not, as the two tuples have a different number of attributes, to start with.
So this analogy is now breaking down.

I suppose I could try to work out here if you really mean that
(using the strict Date sense of the terms here) the relvars are
classes, and the relations that they hold are instances. But that
seems to get a bit sticky too. I think it's better if I wait at
this point for you to provide some further clarification. Would
you mind doing so? Specifically, what is the equivalant of a class,
and what is the equivalant of an instance? What are the consequences
of this, if you know them?

> All _simple_ inheritance problems are easily solved by simple relational
> solutions. The general problem of much more typing and debugging, less
> clues for optimiser etc. are not solved by _simple_ relational
> solutions.

Can you please give me two or three examples of problems that are
not solved by simple relational solutions, and how table inheritance
solves them?

> Of maybe people are diversifying, using inheritance for is-a
> relationships and relational model for has-a relationships.

Well, it seems to me that the relational model better supports the is-a
relationship. With the relational model, I can specify a column in a
table that specifies what that particular entity is, and that can be set
to one and only one value. With the table inheritance model, how are we
ensuring that, if tables R' and R'' both inherit from R, when a tuple
is in R' relating to another tuple in R (or is that the same tuple),
there's not also such a relation between a tuple in R'' and R?

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC