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

J M Davitt wrote:

> paul c wrote:
>

>> J M Davitt wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> J M Davitt wrote:
>>>>
>>>>> Bob Badour wrote:
>>>>>
>>>>>> J M Davitt wrote:
>>>>>>
>>>>>>> Keith H Duggar wrote:
>>>>>>> [snip]
>>>>>>>
>>>>>>> ...
>>>>>
>>>>>
>>>>>
>>>>> Yes.  A broader statement might be, "There ain't nothing the
>>>>> network model can do that the relational model can't do."
>>>>
>>>>
>>>>
>>>>
>>>> Exactly!
>>>
>>>
>>>
>>>
>>> Okay, that being said: it may be that a network model might suit
>>> KDs needs just fine.  All else aside, they can be blazingly fast!
>>> I've seen them used to deliver virtual file systems in *nix
>>> environments and used one to implement a hardware interface device.
>>> (Not an ICE box, but a piece of VME hardware that looked like a
>>> process to a Unix kernel - but was actually a process on another
>>> box.  Way cool.)
>>>
>>> Perhaps I should also emphasize: they can be incredibly difficult
>>> to modify.  One might consider prototyping with a relational
>>> implementation with the intention of implementing on a network
>>> implementation.
>>
>>
>>
>> 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

No, it is deeper than that. One can use two equivalent languages and switch between them rather easily. For example, switching between the relational algebra and the calculus is fairly simple.

The mental gear grinding comes from the mixing of concerns. Whereas the relational model separates the what from the how, the network model forces one to combine both.

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

And anecdotal evidence is worth what, again?

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

When one considers what and how separately, one can easily see the demarcation between them. Knowing each separately and knowing the demarcation, it is relatively easy to weave them together. Once so woven, though, the demarcation become unintelligible. Unweaving them back into what and how then becomes very difficult.

Your doubt does not change the fact that the logical data model is entirely responsible.

  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.

So, don't use SQL products.

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

Implementations, designs and logical data models all make differences. Logical data models affect what one can easily say, which makes the greatest difference in my opinion. When is difficult to say what we want, design becomes much more difficult and prone to failure. Implementation affects mostly performance.

> 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?"

Actually, the logical level is exactly where to answer that question. Of all the logical data models we have devised thus far, only the relational model has anything resembling rigorous design criteria of any kind.

> [This is a long way from the original question about TRM, isn't it?]

It's usenet. Drift happens. Received on Sat May 20 2006 - 18:55:10 CEST