The following
recommendations and rules might help you define the database fields
for your application group:
- You must define at least one database field for the application
group. You can define up to 128 database fields;
however, you should define only as many database fields as you need
to retrieve your reports, and no more. Most customers find that
they typically need no more than three or four database fields to
retrieve any report.
- You must define at least one database field to hold a date or
date/time value, even if the report does not contain a date. If the
report does not contain a date, then you can specify a default value
for the date on the Load Information
page in the application. You can specify any valid date or
you can specify to use the date that the report is being loaded into
the system.
- You must define a database field for each index field that occurs
in the input data.
- If the application group contains more than one application (source
of data), then you must define a database field that identifies the
applications that are assigned to the application group. See Database and Displayed Values for more
information.
- The name of the database field must match the name of an index
field in the index file or you must map the index field to the database
field on the Load Information page in
the application.
- You should identify a date field that Content Manager OnDemand can use to segment the application group index data.
The segment field enables the searching of specific tables of application
group data rather than all of the tables.
- You can set up a database field so that users can search by using
aliases for actual database values. See Database
and Displayed Values for more information.
- For DB2 EEE with a database that resides on multiple nodes, you
can specify the database field that is used to partition the index
data across the multiple nodes. A partition field might enable better
performance for very large databases.
- You can specify the database field that is used as the clustering
index. A cluster index is maintained or improved dynamically as data
is inserted into the associated table, by attempting to insert new
rows physically close to the rows for which the key values of the
index are in the same range. This process might slow the loading of
database rows, but should improve the performance of retrievals (queries
from a client). This option cannot be applied to existing tables;
only new application groups or new application group data tables can
make use of this option.