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

Hi Ed,

> ASSUMING you can get directly to the desired node. That's a big
> assumption.

Yes, In my OODB it is possible. And it is very easy to implement. It is just need to have direct pointer to node.

> More likely it is:
> NDB: navigate to DB, navigate to root Node, navigate to branch Node,
> navigate to target Node, navigate to Field, get Value

Root node can store pointers to all nodes. In any way root can be hidden from application developer. Or on physical leval it is possible to implement global index that have pointers to all nodes.

> Or do you have one grand parent node which points to EVERY node in the
> DB?

Yes. It is Cerebrum.Runtime.NativeSector In my OODB.

> > The same.
>
> There shold be no indices in network model, only pointers.

WHO prohibited use idexes in OODB, and why indices are used in RDB (RM don't has indices too)))

> This is a
> minor point until you include the fact that not all nodes are directly
> accessible.

All nodes can be directly accessible or not - In Cerebrum it is choise of developer.

> So it is more like:
> NDB: navigate to DB, find pointer to root node, navigate to Page,
> navigate to root Node,
> [find pointer to branch Node, navigate to Page, navigate to branch
> Node,]
> find pointer to target Node, navigate to Page, navigate to branch Node,
> find value.

We can store all scalar attributes in the same page as parent node. (NTFS is implemented in such way). So on implementation level all depends from implementation, not from model.

> Consider a "popular" child node, that is a node that has links from
> MANY other nodes pointing to it. Try deleting it. You now have to visit
> every parent node and null out the pointer in each.

Yes.

> In a relational DB this is seldom a problem. Deleting a child row is a
> totally separate operation.
>
> Now consider a parent node. Trry deleting it. How do you handle child
> nodes? Do they just float around waiting for garbage collection if that
> was the last link to them?

In current version of Cerebrum - yes. It is implemented exactly as you described.

> In a relational DB, either: the delete is not allowed due to child
> (Foreign key) constraints
> or the delete cascades down to the child rows deleting them as well.

I don't see technical problems to implement constraints in OODB. I don't implemented them in Cerebrum.

> Network model DBMS that I have seen typically don't need indices since
> the connections are all by pointers.

Yes, it is because and without inices it has performance better then RDB ))) Of course in not all cases OODB is better than RDB without indices. So it should have idices too.

> However an adhoc query may require
> making a JOIN where a link does not exist forces a linear search. Maybe
> this is the case when you are using an index. So the Network
> implementation is no better, but no worse than Relational
> implementation.

Agree. They can be implemented with the same perfomance. Its depends from developer not from model.

But. Network OODB model has native support for trees, graphs, networks. Also it allows classes inheritance and virtual methods. I think You know how trees implemented in current RDBMS, shame ))) And what about graphs? semantic networks?

> But I thought your primary claim of advantage for the Network model was
> performance. IMHO, network DB outperforms Relational DB for the cases
> where the application data model is well defined and thus tuned to the
> data it contains. So it's best case performance is greater than the
> best from a RDBMS. But for adhoc queries or unanticipated application
> changes, network model no longer has direct links to the data. So the
> worst case performance in a network DBMS can be worse than the RDBMS.

In the worst case it is possible to switch from pointers to indices. It is complex task to implementation. I don't implement this yet. But i don't see why it should be impossible in general.

> So you guarantee links are NEVER corrupted? Sorry, but I don't believe
> it. I've seen this problem in other network DBs.

Of course i can't guarantee this. but and RDB can't guarantee that primary keys will be always up to date. I don't see differences here between these models.

> So you just lost your big advantage. For every node access there is
> also and index access. Two disc reads for each node.

It is only for first time. Then DB switches to direct pointers.

> All I can say is I remain unconvinced of your thesis: that relational
> DBs are dead.

My thesis is 'table-based DBMS are potentially dead'.

WBR,
Dmitry Received on Sat Jul 08 2006 - 20:59:35 CEST