Re: Introducing PlayDB (The Model, The Language, The DBMS)

From: Bob Badour <bbadour_at_golden.net>
Date: Fri, 10 Oct 2003 09:20:00 -0400
Message-ID: <pqKdnW1nytitLxuiU-KYuQ_at_golden.net>


"Seun Osewa" <seunosewa_at_inaira.com> wrote in message news:ba87a3cf.0310092308.4a84837f_at_posting.google.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:<ZvCdnetWkJcDhxuiU-KYvw_at_golden.net>...
> > Read Date's and Darwen's _The Third Manifesto_, the book and not the
1995
> > paper, for a sound type inheritance model.
>
> Thanks, Bob. I was able to find the relevant chapter here:
> http://www.hughdarwen.freeola.com/TheThirdManifesto.web/CHAP13.pdf
> And a presentation based on the same topic:
> http://www.hughdarwen.freeola.com/TheThirdManifesto.web/taamoti.paper.pdf
>
> The scheme seems too rather complicated :-( but I am looking at it
> still.
>
> What I am considering here is to get rid of the notion of type
> inheritance altogether and allow each object to simply be (or not be)
> a member of any combination of recognized classes as long as it
> satisfies basic requirements of each class it wants to a member of.

Whether one has a strongly typed computational model or an untyped computational model, values have types. You are arguing for an untyped computational model without any kind of argument or justification.

> One implication of this is that object creation queries will not be of
> the form INSERT RELATION_XXX SET ATTRIBUTE = .... Instead it will be
> like CREATE OBJECT WITH ATTRIBUTES .... ... ... [MEMBER OF CLASSES
> PPP, QQQ, RRR].
This is non sequitur. The former does not imply the latter. All you have done with the latter is remove the ability to express n-ary relations among values and impose a huge cognitive burden on users who must know the full set of types they want each value to have.

> Objects are inserted into "the system" and not into
> tables.

Thereby crippling the system. Without relations, all one has is a hodge-podge of disjoint values without any means to derive new facts from them.

> In the relational model the attributes served as means of
> differentiating one tuple within a relation, but in the model I am
> tending towards the attributes of an object must be able to
> differentiate it from all other objects on the system. That's a
> challenge.

You apparently make one or both of the great blunders, and then you basically restate POOD.

[remainder of nonsense snipped]

When proposing a new data model, one must address the issues of data independence, semantic expressibility, referential integrity and data manipulation among others. The proposed data model must at least match the relational model on all of those points. Your proposal fails even to approach the relational model on any of those points. Received on Fri Oct 10 2003 - 15:20:00 CEST

Original text of this message