Re: types vs. views

From: Mikito Harakiri <mikharakiri_at_ywho.com>
Date: Wed, 3 Sep 2003 10:08:44 -0700
Message-ID: <Smp5b.17$eu1.222_at_news.oracle.com>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:cd3b3cf.0309030652.27cfaff1_at_posting.google.com...
> "Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message
news:<irr3b.16$D94.166_at_news.oracle.com>...
> > 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.

How DBMS would derive the desired representation? Is

TYPE POINT
POSSREP XY_POINT { X NUMERIC, Y NUMERIC } POSSREP POLAR_POINT { A NUMERIC, R NUMERIC } a valid syntax? Now

POINT P := XY_POINT (1,1) NUMERIC ANGLE := THE_A(P) would the last operation succeed or throw an exception? In other words, when specifying N possreps for a type is DBA also required to write doen N*(N-1) conversion operators?

> > 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.

Once again, if manually programmed conversion operators are part of TTM, then the TTM possrep conversion idea is similar to "on update" trigger where DBA must code view updates.

> > 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.

OK.

> 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.

Question. Are observer methods on logical or physical level? Received on Wed Sep 03 2003 - 19:08:44 CEST

Original text of this message