<<The real problem is that with each data set and with all the available
search products available today, one solution could be very slow on some
sets and very fast on others.  Because of the management issues of making
decisions are what method to use when, most customers that I work with
chose one method that is the "best" for their environment.  They may
decide that they will use IMAGE B-trees or a TPI produce all the time.
 Or they may decide they will use SUPRTOOL all the time, or Steve's
method of retrieval, or just a serial read of the data set.  The key is
that the "expected" performance of one of these methods will be faster
than another, and the company is willing to accept somewhat worse
performance in a few cases than to use 6 different methods throughout
their environment.
What's "best" - using multiple methods or choose a single method?  :) :)
Oh, boy, now you're into an area such as religion.  I'm just showing some
of the many options. :)>>


I'd hesitate to call the technique of serial-master-plus-chained-detail
"my" method; it's just, as you mention, one of the several methods that
an IMAGE developer should have in his/her tool kit. Which probably also
indicates my take on the 'What's "best"' question: a single method is,
almost by definition, never going to be the "best" answer for all
situations. Which is one reason I'm really glad that sorted-sequential
indexing is finally becoming available; it's another, really handy to
have, tool to put in the bag.

One of the easily-overlooked issues is that any time you're going to have
to examine a significant percentage of a detail set, like <insert number
here-maybe 30%?> or more, you aren't really using it like a database any
more. As a result, you can get better performance if you don't pay the
overhead of the database-access path. As Larry mentions, an access to the
database through the engine has a cost. By using direct non-buffered
multi-record reads of the detail set, essentially treating it as a flat
file, you can bypass the engine and get much better performance.

Steve