Re: An object-oriented network DBMS from relational DBMS point of view

On 12 Mar 2007 07:46:58 -0700, Daniel Parker wrote:

> On Mar 11, 4:44 pm, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> wrote:
>>
>> I think that static typing should not hinder projections. It depends on how
>> tuples are built. If bare aggregation were used then yes, any traces to
>> commonalities between different types of rows would probably be lost. But
>> there is inheritance to make types related, which is in fact the same
>> relation under a different name.
>>
>> For example: Customer derived from Age, Name, Location, Height.
>
> Okay, so columns have types, in your example Age, Name, Location,
> Height. That's okay, that's consistent with the relational approach,
> and with Third Manifesto.
>
> Now what happens if I want a projection of the Location and Height
> columns, grouped by Name and Age, with counts as another column, and
> maybe joined by Location with some information in another table. What
> "type" is that? And no, I don't want to define that "type" up front,
> before submitting the query, I want it to come into existence as I
> make the query.

I agree with the point about structural vs. named matching made by Marshall.

However, from my stand point I prefer up-front declarations to structural equivalence and inference. This by no means should exclude types algebra. These are different things. The types expression which takes the types Location, Height, Name and Age as operands and yields the type of the column is neither automatically structural nor inference. This type might remain anonymous, be used in some of its [inherited=>automatically generated] operations (=in a "query") and then dropped on the floor. This can still be static and fully checkable (which is my primary concern).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de