Issue 1820:  Implementation problems of IDL for SequentialAccess interface                                                                                                                                          (pids-rtf2)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: In reviewing the documentation and IDL for the SequentialAccess Interface, I came to understand that there would be problems with its implementation.
 
 The problems are:
 a. Access Method
 b.  Performance
 c.  Memory Management
 

Resolution: 
Revised Text: 
Actions taken:
August 18, 1998: received issue
February 25, 1999: closed issue
Discussion: 

End of Annotations:=====
1.	In reviewing the documentation and IDL for the
SequentialAccess Interface, I came to understand that there would be
problems with its implementation.

The problems are:

a. Access Method

HNE uses a relational database to access persons using its 29 base
person traits in person searches.  It is not set up to access the HNE
Enterprise Ids in sequential order.

b.  Performance

Five of the six methods in the interface allow the client to indicate
which person traits should be returned.  In order to accommodate any
changes in the list of requested traits, the HNE person search would
have to be set up to return every available person trait.  Candidate
traits cannot be returned dynamically; the list of traits must be
specified before the search is started.

In addition, requesting every possible person trait would dramatically
impact the performance of the search and the server.

c.  Memory Management

Because HNE returns the list of candidates sequentially, without the
ability to return to previously returned candidates, each candidate
returned would have to be stored in memory in order to support the
"get_previous_ids" and "get_last_ids" methods.

The "get_last_ids" method would be particularly difficult to support
because the method would have to read in each candidate until the end
of the list is maintained and then return the last "n" requested.

The "get_previous_ids" method documentation indicates that the client
will be able to specify a reference Enterprise Id and return the
previous "n" candidates from the reference Enterprise Id.  In order to
implement the method, a cross-reference would have to be created for
each Enterprise Id to indicate which entry in the candidate list it
pertains to.  This would require even more memory for an already
memory intensive interface.
    
Alternatives to storing the candidate list and the Enterprise Id
cross-reference would require disk storage.  Considering that the
interface would already have to return every person trait, the
performance of the interface would be further degraded.

It seems that the SequentialAccess Interface is better suited as a SQL
report.