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."
Received on Fri May 19 2006 - 19:29:06 CDT
