Siebel Performance Tuning Guide > Tuning Customer Configurations > Performance Guidelines for Business Objects Layer >

Guidelines for Using Calculated Fields

This topic is part of Performance Guidelines for Business Objects Layer.

Calculated fields provide a convenient way to access and display data in the user interface that is not directly stored in a table. However, calculated fields have a cost associated with them. Consequently, it is important to use them appropriately to fulfill your requirements, and not to misuse them.

Each calculated field is evaluated whenever the business component is queried to provide a value for the field. Extensive use of calculated fields, or usage in certain contexts, can impact performance. Some guidelines are as follows:

• Use calculated fields sparingly. Be sure there is a valid business case for their usage.
• Minimize the complexity of the expressions defined in your calculated fields.
• Minimize the use of calculated fields that perform Sum, Count, Min, or Max calculations, such as for detail records in an MVG business component. In particular, avoid using such fields in list applets, or in More Info form applets. The cost of using such expressions can be significant depending on the number of detail records.

  Whenever data is totaled there are performance implications. It is important to limit the number of records being totaled. For example, totaling the line items in a Quote or Expense report is not resource-consuming. However, summing the expected revenue for all Opportunities is resource-consuming.

  The latter occurs when you generate a chart. However, charts tend not to be generated frequently. Accessing the Opportunities list view for routine searches and data entry is done frequently.

  CAUTION:  Never put a sum([MVfield]) in a list column. Doing so requires that a separate query be executed for each record in the list, which is a significant performance issue.

• Avoid defining calculated fields using complex expressions that provide different values depending on the current language.
• Avoid using a calculated field to directly copy the value of another field.
• Avoid including calculated fields in search specifications, particularly if the calculated fields use functions that are not supported by the underlying RDBMS.
  • If the RDBMS supports the function, then it will have algorithms for performing the calculations efficiently and will return the calculated values with the result set. However, if functions such as EXISTS, Max, or Count are included, then multiple subqueries can be performed, impacting performance.
  • If the function is not supported in the RDBMS, then the Siebel application might have to rescan the entire result set to perform the desired calculation, considerably increasing the time it takes to obtain the results of the query.

    In the first case, the calculations can take place before the results are returned, while, in the second case, they have to be performed in memory (on the Siebel Application Object Manager or client).

    NOTE:  Even if the calculated field is supported at the RDBMS level, there can be other reasons why a search specification on a calculated field might result in poor performance, such as the lack of an index (for example, when using the LIKE function) supporting the search specification. See Managing Database Indexes in Sorting and Searching.