|Bookshelf Home | Contents | Index | PDF|
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:
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.
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.
For more information, see Options to Filter Data Displayed in an Applet.
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.
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.
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.
For more information see, see How an Extension Table Stores Custom Data.
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.
Using a custom party type compromises access control and remote visibility. For more information, see How the S_Party Table Controls Access.
|Configuring Siebel Business Applications||Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices.|