Re: Modelling Disjoint Subtypes

On Mar 25, 4:05 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Marshall wrote:
>
> > One often wants to consider all the different sub-entities together.
>
> You just punched the tar baby. Entity? What entity?

Heh. You would think that as the inventor of Table/Attribute Modeling I'd know better.

> > If one has ten different disjoint types, and one wants to count
> > them, having a table for the common attributes means the
> > count() can be done with a single table, vs. a join of ten tables.
>
> All of that is irrelevant. The specific constraint was chosen to
> maximize use of foreign key constraints and to minimize general WFF
> usage. That is all.

Fair enough.

> > On the other hand, if one has a query that needs both common
> > and unique attributes, that query would require two tables vs.
> > just one if we didn't have the common attributes in a supertype
> > table. Anyone have any other considerations?
>
> In the general case, one will have both in any case due to the magic of
> views.

Ah! Nice point.

> >>I am not sure I understand the relevancy of your appeal to functional and
> >>OOP point of view.
>
> > You asked about the relevance of disjoint subtypes; I was
> > pointing out how the construct appears in a wide variety
> > of computational models.
>
> Mutual exclusion or disjointedness is a concept. Thus one would expect
> to find that concept expressible one way or another in every
> computational model.

Indeed. I also wanted to get across that this concept is common as dirt, and very important. So much so that in the FP world it is pretty much their fundamental data structure, and much attention is paid on how best to express it and what operators to provide for it. To me that fact seems significant; to others perhaps it will not.

Marshall Received on Sun Mar 25 2007 - 16:35:54 CEST