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

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Mon, 12 Mar 2007 19:55:42 +0100
Message-ID: <1vwh1vpj1xlbs.ujnhwa1tla8y.dlg_at_40tude.net>


On 12 Mar 2007 10:56:43 -0700, Dmitry Shuklin wrote:

> On 10 mar, 12:11, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> wrote:

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

>
> Yes, tables is just a collections. In network OODB table is just a
> node. This node has many attributes. Two of them - collections of rows
> and collections of columns.

Important is uniformity of a collection, i.e. the set of methods which can be defined on the class of all possible members of the collection.

> So table can be row of by self.

Self-recursive types is IMO a bad idea, because the recursion can turn infinite, so that the correctness would become undecidable.

It is better to keep referential and target types distinct. They still can be related. I.e. a reference can be treated as a derived type of the target type and, this way the class of the target type could contain references. But note these would be three distinct types. This way one could put references to tables into tables, keeping the type system sane.

> And columns can be rows in some table.

If types are conform.

> Let take table "Tables" as example.
>
> Table has an attribute Name = "Tables" and it has a column "Name". It
> contains self as a row. And field Name of this row in table "Tables"
> = "Tables".
>
> Let take table "Attributes" for example. Table "Attributes" contains
> rows=attributes descriptors. This table contained by table "Tables" as
> another row. And column Name in "Tables" table for attributes-row =
> "Attributes". Also One of them - descriptor of attribute "Name" - row
> attribute-name descripts all names. So it descripts own attribute name
> = "Name". Also instance of this row is contained in column collection
> of table "Tables" and table "Attributes", also it contains in rows
> collection in table "Attributes".

The advantage of RM is its uniformity. Surely this puts a strict constraint on what could be described, but in the end it ensures some degree of sanity (OK cells are untyped mess, but we don't consider them). In a fully typed system you will have the same effect, on a higher level of abstraction. But that will not be a complete freedom. Yes, you will be able to construct heterogenous collections, but you would loose the operations that don't belong to the most common ancestor class. This would make such collections useless. Of course, that could be circumvented with dynamic typing and a lot of dynamic casts, but this is not the way to go, IMO.

(I think that statically types systems need to be elaborated to be able to describe RA upon ADTs, yes, Third Manifesto x OO.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Received on Mon Mar 12 2007 - 19:55:42 CET

Original text of this message