Used if you expect to find the record, for example when searching a customer file to answer the customer’s inquiry.

Used if you do not expect find the record, for example when searching a customer file to open a new account to verify that this really is a new customer; or when searching a black-list to be sure that the name does not exist.

The above two strategies progress in a different path, the customer inquiry will retrieve one or more records similar to the name and the operator will select one record as the correct one (maybe based on more information supplied by the customer). The positive search wants to process as few records as possible before the operator chooses the match.

The new account search will typically show no records that are the new customer but will show several records with some similarity and the operator will check that these in fact do not represent the new customer. Thus a negative search is required to process all records that are sufficiently like the new customer to pose some risk.

The NAMESET Service supports these two strategies by composing different Search Tables (a Search Table is a parameter passed between the SSA-NAME3 Algorithm and the Application) for the positive and the negative strategy. For the positive case a cascade logic is employed to first define the smallest set that is most likely to contain the customer record and then if necessary allow the set to be widened to solve difficult searches.

In the negative case the Service constructs a search table defining all possible sets that could contain similar records. Because a negative search is one where it is vital that candidates are not missed, one cannot plan to read records "until a match is found" , as with a positive search, but instead a predetermined rule will stop the reading of records at some point and declare the record "not found". The implication of this approach is that a larger set of records is read (compared to the positive approach). At times the volume will be an order of magnitude larger. For this reason you should evaluate the cost of failing to locate a record (when it is present in the data) against the cost of searching for it. In other words, if your application has a negative characteristic (most searches are expected to fail) but the cost of a full exhaustive negative search is prohibitive, then you should use the positive search with your rules on when to declare a record "not found".

In summary, if your application regularly searches for records that are not present in the database, but when the record is present it is very important to locate it, and you are ready to pay the heavy processing cost, then you should use a negative search strategy.

For more information on choosing an appropriate Search Strategy for your application, refer to the

Tips on Choosing a Search Strategy

section in this guide.