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

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 20 May 2006 01:05:12 GMT
Message-ID: <cXtbg.10009$A26.248606_at_ursa-nb00s0.nbnet.nb.ca>


J M Davitt wrote:

> Bob Badour wrote:
> 

>> J M Davitt wrote:
>>
>>> Keith H Duggar wrote:
>>> [snip]
>>>
>>> A particular network may be very convenient
>>>
>>>> for one analysis and a nightmare for other. I'm beginning to
>>>> understand this is the concept of "access paths" correct?
>>>> And that a network model encodes and optimizes a particular
>>>> access path whereas a relational model does not? And thus a
>>>> RM allows many access paths? Efficiently?
>>>
>>> Products which implement the network model require indices
>>> between sets of records (tables) that are to be efficiently
>>> joined. A couple points: it can be done inefficiently
>>> without an index, but it's very inefficient. The joins are
>>> not exactly what the RM considers joins; it's really a way
>>> to specify a subset of the "other" records which are
>>> associated with the current subset of "these" records.
>>>
>>> Network model implementations can really fly, though, because
>>> of the "behind the scenes" features that are part of the workspace
>>> provided in the programming model. That workspace maintains
>>> buffers and "current set of" context for every record type
>>> referred to in the program. That, combined with the ability
>>> to do "greatest which is less than or equal to" and "least
>>> which is greater than or equal to" type "look-ups" in the
>>> "other" records (due to the indexing scheme used) makes for
>>> great speed.
>>
>> You are confusing the physical and logical levels of discourse, which
>> is not so surprising when discussing the network model.
> 
> I carefully sprinkled "implement," "implementations," and
> "implementation tradeoffs" throughout my remarks because
> the things being emphasized are features and consequences
> of implementations -- not the network model.  Perhaps the
> point was not sufficiently obvious.

You clearly distinguished network model implementations from implementations of other logical data models and then proceeded to describe physical features that are not at all unique to the network model.

The attribution of the possibility of implementation benefits to the network model confuses the physical and logical levels of discourse regardless how many times you put 'implement' or 'implementations' or 'implementation tradeoffs' in what you wrote.

>  However, none of
> 

>> the features above are unique to the network logical model.
> 
> Yes.  A broader statement might be, "There ain't nothing the
> network model can do that the relational model can't do."

Exactly! Received on Sat May 20 2006 - 03:05:12 CEST

Original text of this message