This is one of the data gathering methodologies and recommendations for base setup improvement. The full list is defined in the Base Setup Recommendations topic here.
Note: These recommendations are valid for systems without In-Memory. The performance costs are different with In-Memory. For more information, refer to the In-Memory Database Component for STEP section of the Resource Materials in online help here.
A few of the flexible elements of references include:
- Ability to configure with multiple different sources and targets (reference and reference by)
- Are of a certain type (product, asset, classification, etc.)
- Can have metadata attributes
None of these reference configurations independently have a direct impact on performance.
However, objects with many references can have a negative impact on performance since the object needs to be re-approved every time a reference changes. Also, since the approval of an object checks each reference, when the object has thousands of references, approval can become costly in performance. For details, refer to the Oracle KODO Database Layer section of the Base Setup Recommendations topic here.
Inheritance also has an impact on performance because the hierarchy is navigated to identify valid values.
Additionally, navigation across a reference to another object, to fetch attribute values and/or references, is expensive on performance. This is because another database access, and potentially another disk access, is required. For example, navigation via references in business rules to resolve values, resolving calculated attributes, or resolving references during export.
Recommendations
When encountering either of the cases above:
- Verify that references are owned by the object type that requires the fewest number of approvals. An object that owns many references carries the load of the approval process, including verifying approval for all referenced objects.
- Limit the usage of references in business rules, calculated attributes and during export.