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

From: Daniel Parker <danielaparker_at_gmail.com>
Date: 11 Mar 2007 12:11:00 -0700
Message-ID: <1173640260.529830.138060_at_n33g2000cwc.googlegroups.com>


On Mar 10, 6:11 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de> wrote:
>
> > Lets examine data interfaces more elaborately. Interface implemented
> > by the row consists of the definition of signatures of methods, which
> > are applicable to this row, and also of the definition of fields (=
> > columns) which were inherited by this row from base tables.
>
> Forget first about tables. Tables are just unordered sets of rows. You can
> have different sorts of collections. Unordered set is just one case of.
>
> When you want to derive, do it from a type (row). The type of the table is
> another thing. You can get it from some abstract collection type
> constrained by the class of rows (=the type of the element). The iterator
> (index) is another parameter.
>
> Nothing in a type system should prevent you to derive from any type. Tables
> and rows are distinct types. Derivation from a row and from a table are two
> sufficiently different things.
>
Can you explain what kind of algebra you would define over these things, with operations analagous to the relational union, join, projection? What kind of things would such an algebra be closed over? I'm particularly interested in how you would handle arbitrary projections on the properties of the rows. My reading of the original post is that the ability to do projections has been lost, at least it would be with static typing.

Daniel Received on Sun Mar 11 2007 - 20:11:00 CET

Original text of this message