Re: TRM - Morbidity has set in, or not?
From: J M Davitt <jdavitt_at_aeneas.net>
Date: Sat, 20 May 2006 01:57:18 GMT
Message-ID: <2Iubg.27101$YI5.11345_at_tornado.ohiordc.rr.com>
>> 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.
>> 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!
Date: Sat, 20 May 2006 01:57:18 GMT
Message-ID: <2Iubg.27101$YI5.11345_at_tornado.ohiordc.rr.com>
Bob Badour wrote:
> 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.
Well, yes; they are not unique to the network model. They are, however, distinguishing features of network model products -- a point which, it seems, was not well made.
> 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!