Re: TRM - Morbidity has set in, or not?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 19 May 2006 13:50:07 GMT
Message-ID: <j2kbg.9800$A26.243178_at_ursa-nb00s0.nbnet.nb.ca>
>
> 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.
Date: Fri, 19 May 2006 13:50:07 GMT
Message-ID: <j2kbg.9800$A26.243178_at_ursa-nb00s0.nbnet.nb.ca>
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. However, none of the features above are unique to the network logical model. Received on Fri May 19 2006 - 15:50:07 CEST