Re: I think that relational DBs are dead. See link to my article inside

Dmitry Shuklin wrote:
> Hi Cimode
>
> > > > How are they attached?
> > > Via configuration DB. It is like a RDB, it contains tables, rows, ...
> > > but it is not RDB. It is RDB emulation on OODB. So tables, rows and
> > > columns has different behavior. For example row can be contained in
> > > many tables at one time. So if you change row field via one table it
> > > automatically changed in all tables which contains this row.
> > You lost me. On one side, you told me there's no concept of table but
> > now you use table concepts...Please clarify...
>
> Yea, there are no tables as concept and at the same time there are
> "tables".
>
> On the most low logic level of DB the network of nodes or or-graph is
> exists. There are no tables, rows, objects, ... only nodes and links.
> All links are single directional. Each link has a "color" or
> identifier. Each node can have as many links as needed. But each node
> can have only one link with one color. There can't be two or more links
> with the same identifier directed from one node. There can be many
> links with the same color directed to the one node. There can be many
> links with different identifier directed from one node to another. From
> some node you can found other nodes only when you know identifier for
> link to these nodes. Each node knows about and owns links dercted from
> this node. Node doesn't know about links directed from another nodes.

Seems like classic network structure (I'm not sure it is a classic network model. The fact that every node is essentially independent and apparently "freeform" (knowing the structure of the parent tells you little or nothing about a child node).

Problems I've seen with network databases: sometimes there is not way to get directly to a given bit of data. You have to walk the network instead.

Links are fast for access, but updates can be a heavy operation, changing LOTS of pointers. A consequence of this is error recovery. An update that is only partially completed when a system crash occurs (power still gets lost even these days) can wreck the DB. Some DB have functions to "rebuild the links". This can make crash recovery very time consuming and error prone.

>
> Each node can have a .NET object instance attached. In the database the
> root node is exists. the root is the beginning of the database. Each
> persistent object can discover what node is attached to and root node.
>
> links are just pointers. and all works very fast.

maintaining pointers in the achilles heal of network model.

[]
> > > No it is not needed load all network into RAM. You just need to load
> > > one instance which holds count attribute. that is all.
> > So you store the count value? .
>
> Yes. Collection stores value inside own instance. It is one of
> optimization. The most optimization i done - O(1) when searching object
> instance by it ID.

ID or pointer value? Do you expose the internal link values to the application?
(bad idea IMHO)

>
>
> > Again there's no such thing as an RDBMS already implemented.
>
> Ok then when i say 'RDBMS' - read 'table-based DBMS'. For me while it
> don't exists yet it is no matter if MS SQL truely RDBMS or not. It just
> called RDBMS.
>
> WBR,
> Dmitry

Have a good day.
  Ed Received on Thu Jul 06 2006 - 23:10:10 CEST