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

Dmitry Shuklin wrote:
> Hello Ed,
>
>
> > 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).
>
> Yes.
>
> > 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.
>
> It is illusion that RDB is better in such cases. Lets compare RDB &
> NDB.
> For example we need to find some instance attribute by its id.name.
>
> >From abstract logical point of view:
>
> RDB: navigate to DB, navigate to Table, navigate to Row, navigate to
> Field, get Value
> NDB: navigate to DB, navigate to Node, navigate to Field, get Value
>
> NDB is "faster" ))

ASSUMING you can get directly to the desired node. That's a big assumption. 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

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

>
> >From implementation point of view:
>
> RDB: navigate to DB, navigate to Index, navigate to Page, find Row,
> find Value.
> NDB: navigate to DB, navigate to Index, navigate to Page, find Node,
> find Value
>
> The same.

There shold be no indices in network model, only pointers. This is a minor point until you include the fact that not all nodes are directly accessible.
 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.

>
> > Links are fast for access, but updates can be a heavy operation,
> > changing LOTS of pointers.
>
> I don't see this. We can use the same optimization technique as current
> RDBMS uses.

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

> Logic abstraction level can be independent from implementation level.
> Indexes are absent in RM too, and what? It is used well ))

Network model DBMS that I have seen typically don't need indices since the connections are all by pointers. 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.

>
> The performance will be equal. Just data model will differ. And some
> additional sugar in ODB will exists.

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.

>
> > 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.
>
> Who prohibit us use the same transaction mechanism as current RDB uses?
> We can split pages and commit changes only after all transactions is
> completed. From this point of view RDB and NDB are the same.

So you guarantee links are NEVER corrupted? Sorry, but I don't believe it. I've seen this problem in other network DBs.
>
>
> > ID or pointer value? Do you expose the internal link values to the
> > application?
>
> I am use soft pointers. It is indexed IDs. ID for an instance developer
> must define by self. So he can define equal IDs for some different
> objects and make objective JOINS like he can make JOINs in RDB.
>
>
So you just lost your big advantage. For every node access there is also and index access. Two disc reads for each node.

> WBR,
> Dmitry

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

Your created a network model DB that works extremely well for neural net applications. Your extrapolation to the death of relational is a big jump. I expect your DBMS will likely still fail as a corporate DB.  I'll continue to develop for Relational DBMS. It's been paying my bills for some years now, and I expect it to continue for a long time yet.

   good luck.
   Ed Received on Fri Jul 07 2006 - 23:04:56 CEST