Configuring Siebel Business Applications > Reusing Predefined Objects > Guidelines for Reusing a Predefined Object >

Guidelines for Reusing a Predefined Table

If you must create a custom business component because no predefined business component meets your requirements, then you must decide to reuse a predefined table or to create a new table. You must only reuse a predefined table that is a suitable fit. Several reasons exist for this guideline:

• Oracle tunes the indexing for the table for the originally intended use. Using it for an alternative purpose might reduce performance.
• The user key table for the unique indexes might not meet your requirements. For a predefined table, you cannot modify these objects. If a user key column does not contain the required data, then the uniqueness of the record, performance, and Enterprise Integration Manager might be compromised.
• The dock object visibility rules might not meet your requirements. Modifying the rules for the table might compromise Siebel Remote. For more information, see Configuring Dock Objects for Siebel Remote.

If you do not reuse a table appropriately, then future reuse of that table for the original purpose of the table might be difficult. For example, assume you use the S_CALL_LST table to store data that is not related to a call list. If you later implement predefined list management, then Siebel CRM displays data that is not related to the call list in the list management views. Adding a search specification to remove this data might compromise performance, and adding an index might or might not correct this problem. For more information, see Options to Filter Data That Siebel CRM Displays in an Applet.

You must not modify any repository table. If the Type property of a table is Repository, then it is a repository table.

For more information, see Reusing Predefined Objects.

Guidelines for Overloading a Table

You might overload a table if you reuse it multiple times on different business components, and if each business component includes a search specification in a Type field. For example, if you use the S_EVT_ACT table to store regular activities, audit logs, error logs, messages, EAI logs, and so on.

If you overload a table, then to prevent Siebel CRM from display data from one business component in another business component, it is often necessary to add a search specification that queries a Type field.

Overloading a table can cause the following problems:

• The search specification that Siebel CRM uses to type the table into various business components might cause performance problems. Siebel CRM might not design the table to be overloaded. For example, it often uses the TODO_CD column of the S_EVT_ACT table to set the type of the table. Siebel CRM does not denormalize this table on to the S_ACT_EMP intersection table for activities and employees. A query that uses the sales representative visibility against a business component that references the S_EVT_ACT table might result in poor performance.
• No guarantee exists that adding indexes against these type columns will resolve a performance problem because adding an index might compromise performance elsewhere. The fact that Siebel CRM might not denormalize a type column onto a position, employee, or organization intersection table might affect a query in some views.
• Overloading a table increases the table size.

For more information, see Options to Filter Data That Siebel CRM Displays in an Applet.

Oracle Designs Some Tables to Be Overloaded

Oracle designs some tables in the Siebel repository to be overloaded. For example, the S_ASSET table uses the TYPE_CD column to set the type for various business components. Oracle denormalizes and indexes this column onto the S_ASSET_POSTN and S_ASSET_BU intersection tables to improve performance in SalesRep and Organization visibility views. Siebel CRM designs some XM tables, such as S_ORG_EXT_XM, to be overloaded.

Guidelines for Using an Extension Table as the Base Table of a Business Component

You must never use an Extension or Extension (Siebel) table as the base table of a business component. Siebel Enterprise Integration Manager and Siebel Remote assume that the PAR_ROW_ID and ROW_ID columns on these tables are equivalent and that the PAR_ROW_ID column references a valid parent table record. For more information, see Extension Columns of a Siebel Table.

Guidelines for Creating a New One-To-One Extension Table

In most situations, you must extend the base table or reuse an ATTRIB column on a one-to-one extension table. Rare instances exist when you must create a new one-to-one table, such as to add a LONG column because you cannot add it to a base table and because Siebel CRM supports only one LONG column on a table. For more information, see Creating a LONG Column on an Extension Table.

Guidelines for Creating a New XM Table

In most situations you must reuse a predefined XM table to support a one-to-many relationship from a base table. If you use an XM table, then use the following guidelines:

• Very few situations exist that require you to create a new XM table. Siebel CRM already tunes XM tables to support large data volumes and multiple data types. Before you create a new XM table, make sure to examine the predefined XM tables to determine whether one meets your requirements.
• In some instances, a base table does not reference an XM table. Instead of reusing another unsuitable predefined table because it contains a foreign key to the base table, you must create a new table. For example, if you require a one-to-many business component from the S_EVT_ACT table, then you must create a one-to-many table rather than reuse a table that might be inappropriate, such as the S_ACT_TIMESTAMP table, provided that the business component does not store timestamp information.

For more information, see How an Extension Table Stores Custom Data.

Guidelines for Using a Table That Is Not an Intersection Table to Create an Intersection

You must reuse an intersection table only where it is a true intersection between two tables. The type of table must be Data (Intersection). Do not use a table that is not an intersection table as an intersection table only because it contains a foreign key to the table. This configuration can overload the table. For more information, see Reusing Predefined Objects.

Do not use a one-to-many XM table as an intersection table. Siebel CRM does not tune an XM table for this usage, and using it as an intersection table might cause poor performance. To support one side of the relationship, you must create a custom foreign key. This configuration might cause problems with Siebel Remote and Enterprise Integration Manager.

If no suitable intersection table exists between two tables and one is required, then you must configure the database. For more information, see How an Extension Table Stores Custom Data.

Guidelines for Using a Table That Is Not Licensed

Do not reuse an unused table that is not licensed for your configuration.

Guidelines for Using the S_PARTY Table to Support a Custom Party Type

Using a custom party type compromises access control and remote visibility. For more information, see How the S_Party Table Controls Access.