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

From: Marshall <>
Date: 12 Mar 2007 08:01:59 -0700
Message-ID: <>

On Mar 12, 6:46 am, "Daniel Parker" <> wrote:
> On Mar 11, 4:44 pm, "Dmitry A. Kazakov" <>
> 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.

People often mistake this issues as a static type vs. dynamic type one. But the difference here is nominal vs. structural. Most dynamic languages use a structural type system, and most (familiar) statically typed languages use a nominal type system, so it's easy to see how the confusion occurs.

The above problem (what type is something that looks like (x, y, z) if we haven't defined it ahead of time) is essentially not solvable in a nominal type system, and that same problem doesn't exist in a structural type system. In a structural type system, the type of something is exactly its "shape" or the types of its components. Types don't need to be predefined. There are a few statically typed languages that work this way: SML and SQL come to mind.

Marshall Received on Mon Mar 12 2007 - 16:01:59 CET

Original text of this message