Re: types vs. views

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:<irr3b.16$D94.166_at_news.oracle.com>...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:62g3b.53$Zb3.7844959_at_mantis.golden.net...
> > I find it interesting that you chose the example you chose. Ironically,
> the
> > example clearly demonstrates how D&D's proposed type system helps with
> view
> > updatability. Obviously, the type system must have some efficient method
> to
> > convert from each declared possible representation to the supported
> physical
> > representations and vice versa. If one considers Point with both polar and
> > cartesian possible representations, then the problem you mention above
> > simply disappears.
>
> I find it interesting that you are bringing up the types. IMO, this example
> demonstrates that type system is overrated. What is the benefit having a
> base type Point and two descendants CartesianPoint and PolarPoint?

I have not made any such suggestion. I have specified a single Point type with two representations and no descendants.

> OK, we
> can clearly have a Point column used in some other relation, for example
> Circle:
>
> table Circle (
> center Point,
> radius Number
> )
>
> Therefore, some tuples would have CartesianPoint while the others PolarPoint
> implementation - that's the idea, right?

It might be. The DBA might specify any physical representation from which the dbms can derive the relation. The dbms might physically represent circles as two pairs of opposing points on the circumference of the circle. The dbms would derive the center point as the intersection of the line segments joining each pair of points and the radius as half the distance between either pair of points.

> I disagree.

You disagree with what? You have not accurately described my position so I am not sure what you disagree with.

> When quering how many circle center points are positioned in
> vicinity of some point, for example, we would like to know Polar coordinates
> for all the tuples, no matter what internal representations they have.

The type system in TTM allows (even encourages) this. The DBA might specify a polar physical representation, but this doesn't matter because the dbms can derive the desired representation from any physical representation.

> Likewise, it would be convenient to manipulate Cartesian representation
> exclusively in some other queries.

Exactly, and the type system in TTM allows exactly this.

> Both queries could be answered if we have
> 2 views CartesianPointCircleCenter and PolarPointCircleCenter and just a
> single representation for the Point.

This is a straw man. You have already remarked on the updatability problem this causes and that the type system in TTM solves.

> I can't possibly see the
> benefit of having heterogeneous list of Points in the database design.

At the logical level, there is no heterogeneous list. Whether it is heterogeneous at the physical level is irrelevant to expressibility and affects only performance.

> Returning to your idea that type system eliminates view update problem I
> fail to see that too. If you are implying that Point would have "getter
> "methods returning both Cartesian and Polar coordinates in it, then it's
> essentially a procedural implementation of inverse view inside a type. Not
> to mention that "fat" types are disgusting, as every time you introduce new
> subtype you have to add more methods inside base type definition.

I am not implying anything that isn't stated explicitly in TTM. There are no "getter" or "setter" methods in TTM. Getting and setting focuses on the physical location of variables and not on the logical meaning of values. In the TTM type system, adding a subtype requires no change to its supertypes.

I can only suggest you study the type system described in TTM and then reapply your imagination to my idea. Received on Wed Sep 03 2003 - 16:52:22 CEST