On Mon, 2002-08-12 at 13:14, Curt Sampson wrote:
> On 12 Aug 2002, Hannu Krosing wrote:
>
> > Are you saying that inheritance in SQL is something fundamentally
> > different than inheritance in OO languages ?
>
> Yes.
>
...
> So is an instance a relation (a set of tuples) or a tuple?
An instance is a tuple. The relation is the Class. The relation header
is the class definition.
> 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.
Yes.
> 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.
The classes C and C' also have different number of 'attributes', but
what matters, is that C' has all the attributes that C has, so you can
use an instance of C' everywhere an instance of C is needed. The same is
true of table inheritance - tuple from R' has all the attributes that a
tuple from R has.
...
> > 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?
>From implementors POW:
Updatable VIEWs
The subset of 'views' that inheritance creates are updatable by default
with no additional effort from the programmer. It is ready for
inheritance because it is inherently more difficult to solve the view
updatability problem for a general case than for the limited set of
views used by inheritance.
> > 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.
When using inheritance both of these (defining and setting) are done
automatically.
> 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?
In OOR _model_ we define a constraint.
In postgreSQL we first fix the constraints spanning inheritance trees
problem and then define a constraint ;)
-------------
Hannu
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
