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!
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.
Received on Fri May 19 2006 - 20:57:18 CDT
