Re: Clean Object Class Design -- What is it?

<D_at_B.A> wrote in message news:yVH17.10886$Kf3.118667_at_www.newsranger.com...
> In article <fYy17.665$G42.294_at_newsfeed.slurp.net>, Rico says...
> >Now the update on that container means asking the object "what kind of
 thing
> >are you?" and then executing one of two kinds of update statements based
 on
> >the response.
>
> The first problem is that some x might answer "both".
>
> Answering your question literally:
>
> select AB.x x, "B" type from AB
> union
> select AC.x x, "C" type from AC
>

I agree this works for queries, but you'll notice I asked for an update. That's a bit more of a problem, because now you have to determine which table, AB or AC, you need to run the update statement on. Also, in your example, as the number of child classes grow, you have to keep changing your queries. In an object-oriented system, adding child classes wouldn't affect any logic that was working in terms of the parent's attributes (i.e. you would have to change the code).

> (I found nore intuitive to rename your tables to AB and AC)

Agreed, easier to read that way.

>
> You need to be more specific about what you want to do polymorphically in
 order
> to get more reasonable answer how would we translate it into relational.
 There
> is no such thing as abstract problem modelling in the relational, we need
 a
> concrete schema to start with.
>

The problem you'll find in this case is that I've presented you with an OO schema, and there are only a few transforms that can be performed to get it into an relational schema. None of them are entirely satisfactory (from an OO perspective), but they can get the job done. Generally the tradeoff is more queries/updates or more space, but as was pointed out in a response by someone else ... the space tradeoff can be mitigated.

> >The final option, and the one you mention in your response, is to put all
> >attributes of every class in the inheritance tree into a single relation.
> >An additional field can then indicate what kind of object it is. Problem
> >with this is obvious: you'll waste a lot of space if you have a
> >moderately-sized application. A lot of your fields will be empty because
> >you'll only use a subset of them at any given time.
> >
> Make it a view
>
> select AB.x, AB.y, AC.z from AB, AC where AB.x=AC.x
>
> then, what's the problem?
>

This is an approach I hadn't considered (I like it). We'll have to make a few assumptions:

1. The database supports updatable views of this nature
2. That we are willing either manually or with automated tool assistance to deconflict child classes that use the same names for an attribute, but draw their values from different domains.

We'll still be saddled with a conceptual problem, however. I don't like inheritance trees that grow beyond 4 or 5 levels ... but even at this level, that can create a lot of child classes. This makes the view have a large number of fields and can be quite awkward to deal with. However, if there is automated tool support, and the implementation is hidden from the programmer ... then even this may not be a big deal. Received on Sun Jul 22 2001 - 01:34:35 CEST