[Info-vax] Indexed file read question
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Wed Nov 18 12:24:04 EST 2020
On 2020-11-18 16:35:41 +0000, abrsvc said:
> On Wednesday, 18 November 2020 at 11:20:54 UTC-5, Stephen Hoffman wrote:
>> On 2020-11-18 15:23:13 +0000, abrsvc said:
>>
>>> Situation: Indexed file with 2 keys, the first key no duplicates,
>>> second key no duplicates. For clarity, the first key is a record
>>> number and the second key is one of 4 values: A,B,L or blank.
>> With only four records possible, why is this even a file? Which
>> implies there *are* duplicates on the secondary?
>
> I have over simplified the situation just to provide a context for the
> question. This is just one of many questionable practices wihtin this
> code system.
> More time is spent opening and closing files with singular records than
> anything else. I am not in a position to change this, I am just trying
> to assist with understanding how the current system works.
>
> Update: There are duplicates for the second key.
I've long assumed the order of record retrieval is indeterminate when
switching to a secondary key with duplicates; that's what is documented.
That secondary key would usually be created as a segmented key here, if
the primary is to (also) be involved in the ordering of secondary
record retrieval.
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list