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 is suitable, 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 technical and functional fit. There are several reasons 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 change 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 that adding an index might or might not correct. For more information, see Options to Filter Data Displayed in an Applet.

For more information, see Reusing Predefined Objects.

Guidelines for Overloading a Table

You can overload a table if you reuse the same table multiple times on different business components, and if each business component is typed with a search specification. For example, if you use the S_EVT_ACT table to store regular activities, audit logs, error logs, messages, EAI logs, and so forth.

If you overload a table, it is often necessary to add a search specification against a Type field to prevent data from one business component from displaying in another business component.

Overloading a table can cause the following problems:

• The search specification used to type the table into various business components might cause performance problems. Often, the table is not designed to be overloaded. For example, the TODO_CD column of the S_EVT_ACT table is often used for typing the table. This table is not denormalized 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.
• There is no guarantee that adding indexes against these type columns will resolve a performance problem because adding an index might compromise performance elsewhere. The fact that the type columns are often not denormalized onto position, employee, or organization intersection tables affects queries in certain views.
• Overloading a table increases the table size.

For more information, see Options to Filter Data Displayed in an Applet.

Oracle Designs Some Tables to Be Overloaded

Oracle designs some tables in the Siebel repository to be overloaded. For example, in Siebel Industry Applications, the S_ASSET table uses the TYPE_CD column to type 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. Also, XM tables, such as S_ORG_EXT_XM, are built to be overloaded.

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

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. However, there are rare instances 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 given 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:

• There are very few situations 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 if 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, see How an Extension Table Stores Custom Data.

Guidelines for Using a Table That Is Not an Intersection Table to Establish 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 desired table. This technique can overload the table. For more information, see Reusing Predefined Objects.

Do not use a one-to-many XM table as an intersection table. Because Siebel CRM does not tune an XM table for this usage, using it as an intersection table might cause poor performance. To support one side of the relationship, you must also create a custom foreign key, which can 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 customize 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.