types vs. views

"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? 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?

I disagree. 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. Likewise, it would be convenient to manipulate Cartesian representation exclusively in some other queries. Both queries could be answered if we have 2 views CartesianPointCircleCenter and PolarPointCircleCenter and just a single representation for the Point. (We would have to arbitrarily decide whether it's Cartesian or Polar and stick to it). I can't possibly see the benefit of having heterogeneous list of Points in the database design.

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. Received on Thu Aug 28 2003 - 19:51:57 CEST