Re: TRM - Morbidity has set in, or not?

paul c wrote:

> J M Davitt wrote:
> 

> 
> 
> I think this is a false kind of comparison.  Surely the network model, 
> if it is a logical model, is a subset of the "symmetrically exploitable" 
> rm (if one excepts the "next"-style operators?  OTOH, some relational 
> schemas could exploit a network physical impl'n.
> 
> p

I thought more about this after making the post, wondering whether it is practical to prototype in one and implement in the other. It would seem to make sense, but...

Whenever I've had to slip into network model mode, mental gear grinding had always occurred. Is that only because different languages are used?

P's point is that, besides the "next"-style operators, there should be no difference in the logical models. BB, I think, made the same point; additionally, he points out that there's no physical feature provided in network model implementations that isn't available in other products.

Given that: it should be a slam dunk. But my experience's haven't been. Slam dunks, that is.

Before continuing...

As for those pesky "next"-style operators: Just to make sure, we're talking about those things that are analogous to ISAM's START verb, right? The T-joins that Codd described in RM/v2, right? (I'm sure it's known by many other names...)

Back to experience... and I don't have a lot of this cross-implementation variety...

Going from SQL products to, say, dbVista, was never much of a problem. There was some significant additional physical design to be done, but that's about it -- besides the language changes, of course.

Going the other way has been a nightmare -- but I'm not sure it's because of the underlying model used to implement the source system. I think inappropriate use of the features provided in network implementations caused problems. More than anything else, it was those pesky "look in the index and find the next (or previous) one of ___" constructions that enabled the developers of the original system to push a faulty logical design beyond the bounds of reason. (This behavior isn't restricted to nm world; I've seen plenty of pushes in SQL-land, too.) And, in a system holding significant amounts of data, the run-time cost of trying to mimic such code in SQL products has been huge.

What's the point? It's not the implementation that makes the difference; the logical design does. If that's broken, there's no good way to move a product from one implementation to another. If it's not, there's not much of a problem.

And, I suppose, this moves the question from the "network v. relational" arena since it's become, "How does one know whether a design is good?"

[This is a long way from the original question about TRM, isn't it?] Received on Sat May 20 2006 - 12:42:30 CEST