Configuring Siebel eBusiness Applications > Overview of Configuring Siebel Applications > About Object Reuse >

About Reusing Tables

If you have decided to create a custom business component because no out-of-the-box business component is suitable, you must also decide whether to reuse an existing table or create a new one.

Again, it is important to only reuse an out-of-the-box table that has a suitable technical and functional fit. There are several reasons for this:

• The table's indexing is tuned for its originally intended use. Using it for alternative purposes may result in performance difficulties.
• The table's user key and unique indexes may not suit your requirements. For out-of-the-box tables, these are not changeable by the developer. Inappropriately populating user key columns may compromise the uniqueness of the record, performance, as well as Siebel EIM.
• The dock object visibility rules may not suit your intended use. Misusing the table may compromise Siebel Remote.

If a table is reused inappropriately, it may make it difficult to reuse that table in the future for its original purpose. For example, you may choose to use the S_CALL_LST table to store data unrelated to call lists. When you decide to implement out-of-the-box list management functionality, unrelated data will be displayed in the list management views. The addition of search specifications to remove this data may compromise performance that may or may not be fixable with the addition of indexes.

The following are some factors that may influence your decision to reuse versus create a new table definition.

• Overloading of tables. Occurs when you reuse the same table multiple times on different business components and each business component is "typed" with a search specification. For example, you may choose to use the S_EVT_ACT table to store regular activities, audit logs, error logs, messages, EAI logs, and so forth.

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

  Overloading of tables may cause several issues:

  • The search specification used to "type" the table into various business components may cause performance issues. Often, the table is not designed to be overloaded. For example, on the S_EVT_ACT table, the TODO_CD column, which is often used for "typing" the table, is not denormalized on to the S_ACT_EMP activity/employee intersection table and queries using SalesRep visibility against a business component based on the S_EVT_ACT table may result in compromised performance.
  • There is no guarantee that the addition of indexes against these "type" columns will resolve any performance issues because adding one may compromise performance elsewhere. Again, the fact that the "type" columns are often not denormalized onto position, employee, or organization intersection tables will have an impact on queries in certain views.
  • Overloading of tables increases the table size.

    NOTE:  Some tables in the Siebel repository have been built to be overloaded. For example, in Siebel Industry Applications, the S_ASSET table uses the TYPE_CD column to "type" various business components. This column is denormalized and indexed onto the S_ASSET_POSTN and S_ASSET_BU intersection tables to aid performance in SalesRep and Organization visibility views. Also, XM tables such as S_ORG_EXT_XM are built for overloading.

• 1:1 Tables as base tables of business components. Tables of type "Extension" or "Extension (Siebel)" should never be used as the base table of a business component. Siebel EIM and Remote assume that the PAR_ROW_ID and ROW_ID columns on these tables are equivalent and that the PAR_ROW_ID column points to a valid parent table record.

  For more information about 1:1 extension tables, see About Extension Columns.

• New 1:1 tables. There are rare instances when you would need to create a new 1:1 table. In most cases, you would simply extend the base table or reuse an ATTRIB column on a 1:1 _X table. However, you may need to create a new 1:1 table to add LONG columns, since they cannot be added to base tables and only one LONG column is supported on a given table.

  For more information about LONG columns, see Creating Columns of Type LONG.

• New 1:M tables. In most cases you would simply reuse an existing XM table to support a 1:M relationship off a base table. The following guidelines should be followed when using an XM table:
  • There are very few cases where you would need to create a new XM table. XM tables are already tuned to support large data volumes and of multiple data types.
  • In some instances, a base table does not have any XM tables. Instead of reusing another unsuitable out-of-the-box table merely because it has a foreign key to the base table, it may be necessary to use database extensibility to create the new table. For example, if you require a one-to-many (1:M) business component from S_EVT_ACT, you should create a 1:M table rather than reusing a table that may be inappropriate, such as S_ACT_TIMESTAMP, provided that the business component is not storing timestamp information.

    For more information about 1:M extension tables, see About Extension Tables.

• Intersection tables. You should reuse an intersection table only where it is a true intersection between the two tables. The table should also be of type "Data (Intersection)".

  You should not use a non-intersection table as an intersection table just because it contains foreign keys to the desired tables. This results in an overloading of the table. For more information about overloading tables, see About Object Reuse.

  Also, 1:M XM tables should not be used as intersection tables. Performance of an XM table is not tuned with this in mind, and using it as an intersection table may cause performance degradation. In addition, a custom foreign key will most likely need to be created to support one side of the relationship, resulting in issues with Siebel Remote and EIM.

  Where no suitable intersection table exists between two tables and one is required, it would be necessary to use DB Extensibility to create it.

  For more information about intersection tables, see About Extension Tables.

• Licensing. Unused tables that are not licensed for your configuration cannot be reused.
• Custom party types. The S_PARTY table should not be reused to support custom party types. The S_PARTY.PARTY_TYPE_CD column only supports one of the following: AccessGroup, Household, Organization, Person, Position, UserList. Use of custom party types will compromise access control and remote visibility.

  For more information about S_PARTY, see About the S_Party Table.

• Repository tables. Repository tables should not be misused by the developer. Repository tables are those that are used by business components prefixed with "Repository."