Adabas Audit Data Retrieval supports two types of list-related indexes: primary indexes and secondary indexes.
A primary index stores the indexed values in alphabetical order. A primary index is efficient when looking for a specific value.
A secondary index stores the indexed values ordered by page number (or item number). A secondary index is efficient when looking for the values that are located on a specific page (item).
Secondary indexes are therefore efficient only when used in combination with primary indexes. Secondary indexes are suitable when finding the common hits in AND queries where one query returns a relatively small number of hits (primary index) and the other query returns a relatively large number of hits (secondary index).
Secondary indexes are sorted by page number (item number). Adabas Audit Data Retrieval achieves this by creating a two part index key during index generation: the first part of the index key is the page number (or item number) and the second part of the index key is the actual value to be indexed.
Example
If a primary index is created for the types of bookings in an account list, the index key contains the values CHEQUE, CREDIT, INTEREST, etc.
If a secondary index is created for the types of bookings in an account list, the index key contains the values xxxxxxxxCHEQUE, xxxxxxxxCREDIT, xxxxxxxxINTEREST, etc. where xxxxxxxx is the page number (or item number) where the value was found.
An account list includes the fields account number and booking type. If a primary index is created for both account number and booking type, then a query like "Find all bookings of the type CHEQUE for account 123456" is processed like this:
Step 1: Retrieve all hit pages for value 123456 in the first index (account number)
Step 2: Retrieve all hit pages for value CHEQUE in the second index (booking type)
Step 3: For each hit page returned by second query, check whether it is also contained in the first hit list
Result: All hit pages containing bookings for account 123456 with the booking type CHEQUE
If a primary index is created for account number and a secondary index for booking type, then a query like "Find all bookings of the type CHEQUE for account 123456" is processed like this:
Step 1: Retrieve all hit pages for value 123456 in the first index (account number)
Step 2: For each hit page do the following:
Retrieve the hit pages for the value xxxxxxxxCHEQUE in
the second index (booking type), where xxxxxxxx is the page
number of the hit retrieved in step 1
Results: All hit pages containing bookings for account 123456 with the booking type CHEQUE
In the second case (with secondary index) the selection described in step 2 is carried out several times, namely once for each hit page retrieved from the first index. However, step 3 is omitted and therefore the total number of operations executed is considerably smaller than in the first case (without secondary index).
A secondary index is defined via the field Index Level on page 1 of the index definition:
1 = Primary index
2 = Secondary index
Before you define an index as a secondary index, you should be aware of the following:
Recommendation: Defining required fields
Corresponding definitions should prevent users from submitting queries that do not involve the use of a primary index. To force users to enter values in the corresponding fields, you can use the field Input required in the index definition of the primary index or in the corresponding layout definition of the query mask. The value specified in the index definition is stored in the generation record at read-in time and is valid when the query mask is generated dynamically. When a user-defined query mask is used instead, the value in the layout definition applies.
Under certain conditions it may make sense to define two indexes for the same values, namely only primary index and one secondary index.