Application and Database Design Guide

10.2
- 10.5 HotFix 1
- 10.5
- 10.2 HotFix 1
- 10.1
- 10.0 HotFix 1
- 10.0

Back Next

Design Tips for Application Performance

In addition to the information provided above, this section contains some general tips that will help the developer build a program that performs well.

More programming language specific tips may be found in the

API REFERENCE

guide.

Searching

Choosing an Appropriate Search Level

To choose an appropriate Search level, it is well worth spending time understanding the business and performance needs of the search. As there is a natural conflict between performance and reliability, care should be taken when choosing the Search Strategy to use for any given application.

Testing should be performed using different Search Levels on real production data. Measures of reliability (the percentage of known matches found) should be considered against measures of performance (how long the search transaction or batch job took) and both should be looked at in view of the business requirements.

When measuring reliability, it is best to have a known set of expected search results. When measuring performance, in addition to ensuring the actual production volume of data is being searched, also take into account network and machine load overhead.

For more information on choosing an appropriate Search Strategy, see the Choosing Search Strategies
chapter.

Partitioning Keys

In some systems that have extreme numbers of records to index, it may make sense to investigate the use of

SSA-NAME3

key partitioning. This is purely a user design choice, and is not an internal

SSANAME3

option.

The way partitioning is implemented depends on the database design and capabilities. In some designs, a high-order part will be added to the

SSA-NAME3

key by the key-building application program after the key has been generated, and prior to it being stored in the database. It requires the column that holds the

SSA-NAME3

key field to be large enough to hold the partition + key.

In other systems, the database itself may be instructed to build a "concatenated" key from two separate columns, the partition value and the

SSA-NAME3

key.

Key partitioning has its down-side. Candidates will be missed when the partition is incorrect, and if the search is not designed to search all partitions when the search partition value is null, also when the partition is missing. As such, this design choice may not be suitable for critical search systems where there is a high risk associated with missing a match.

Matching

Using Filters

If the business purpose of the match requires filtering of candidate records based on the settings of flags in the record, then using Match Filters in the

ssan3_match

call will perform better than doing the filtering after the match call.

Code Optimization within the Match Loop

In a typical SSA-NAME3 search and match application, the loop that calls

ssan3_match

for each of the candidate records returned from the search will be executed more often than any other segment of code. Additional care taken to optimize the performance of the code within this loop will help make your SSA-NAME3 searches perform better.

Some suggestions for optimizing code within this loop:

Try to limit the movement or copying of data to a minimum within the loop.

If developing in an Object Oriented Language, try to limit the creation of new objects within the loop.

For a given set of candidate records, format the Search Data string only once outside the loop that calls

ssan3_match

. The Search Data string should be the same for each match call within a given search and formatting it each time would waste CPU cycles.

Rename Saved Search

Table of Contents

Application and Database Design Guide

Application and Database Design Guide

Design Tips for Application Performance

Design Tips for Application Performance

Searching

Choosing an Appropriate Search Level

Partitioning Keys

Matching

Using Filters

Code Optimization within the Match Loop