Re: types vs. views

From: Leandro Guimarães Faria Corsetti Dutra <lgcdutra_at_terra.com.br>
Date: Sat, 30 Aug 2003 13:25:02 +0200
Message-Id: <pan.2003.08.30.11.25.01.86848_at_terra.com.br>


On Thu, 28 Aug 2003 10:51:57 -0700, Mikito Harakiri wrote:

> this example demonstrates that type system is overrated.

        I think your answer demonstrates you didn't get it... you're mixing possible representations with hierarchies. While POSSREPs are quite simple, powerful and uncontroversial, type hierarchies is a nice proposition that isn't essential not even to _TTM_, and has been dumped from D4 for its complexity, with D&D's blessing.

> What is the benefit having a
> base type Point and two descendants CartesianPoint and PolarPoint?

        These are not descendants, but POSSREPs.

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

        No.

        The DBA would choose which representation gets stored. The user can use both as he wishes to query and update, but only the DBA choice gets stored.

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

        Yes, but it is not quite procedural, as the POSSREPs have already been declared in the type definition and providing the conversion logic would be trivial.

        But again, you are missing the point. You are insisting on type conversion, which is a nice thing to have but irrelevant to the relational model, as it pertains to what happens 'inside' the types, not on the relations' level.

> "fat" types are disgusting, as every time you introduce new
> subtype you have to add more methods inside base type definition.

        You really didn't get _TTM_'s type hierarchy... it's totally contrary to what you claim; base types aren't fat but lean; new methods are added only to subtypes, and base type methods work for all subtypes, with possibly overloading of subtype-defined operators.

-- 
 _   Leandro Guimarães Faria Corsetti Dutra     +41 (21) 648 11 34
/ \  http://br.geocities.com./lgcdutra/         +41 (78) 778 11 34
\ /  Answer to the list, not to me directly!    +55 (11) 5686 2219
/ \  Rate this if helpful: http://svcs.affero.net/rm.php?r=leandro
Received on Sat Aug 30 2003 - 13:25:02 CEST

Original text of this message