Profiling System Design Considerations
This section describes the following considerations for designing effective profile definitions:
- Keys
- Recommended data type mappings
- Other considerations
Keys
Choosing the appropriate key members can help you maximize the performance of the Profiling System. To effectively define keys in the profile definition, answer the following questions, and then use the table to find the corresponding guideline:
- Question 1. Should the primary key property be updatable after the object has been committed to the underlying stores?
- Question 2. Should the data be partitioned within a data source?
| Guideline | Question 1 | Question 2 |
|---|---|---|
| Use the same property as the primary key and the join key. | No | No |
| Use the same property as the primary key, the join key, and the hashing key. This configuration maximizes the performance of Profiling System operations in partitioned scenarios. | No | Yes |
| Do not use the same property as the primary key and the join key. | Yes | No |
| Do not use the same property as the primary key and the join key. However, use the same property as the join key and the hashing key. This configuration provides sub-optimal performance for profile object operations based on a non-hashing (or non-join) key property. | Yes | Yes |
Recommended Data Type Mappings
The following tables list the recommended mappings between Profiling System data types and the data types supported by SQL Server, Oracle, Active Directory, and Membership Directory.
ANSI SQL stores
| Profiling System data type | SQL Server data type | Oracle data type |
|---|---|---|
| BOOL | smallint | number |
| NUMBER | int | number |
| FLOAT | float | number |
| STRING/PROFILE/PASSWORD/ SITETERM | nvarchar | nvarchar2 |
| CURRENCY | money | number |
| DATETIME/DATE/TIME | datetime | date |
| BINARY | varbinary | raw |
| LONGTEXT | ntext | nclob |
| IMAGE | image | blob |
LDAP-v3 stores
| Profiling System data type | Active Directory data type | Membership Directory data type |
|---|---|---|
| BOOL | boolean | integer |
| NUMBER | integer | integer |
| STRING/PROFILE/ PASSWORD/SITETERM | string (Unicode) | UnicodeString |
| CURRENCY | LargeInteger | integer |
| DATETIME | string (GeneralizedTime) | generalizedTime |
| BINARY | string (Octet) | binary |
| LONGTEXT | string (Unicode) | UnicodeString |
| IMAGE | string (Octet) | binary |
.gif "Ee825002.note(en-US,CS.20).gif")
Note
- For ANSI SQL stores, the Profiling System supports multi-values only for the string data type. For LDAP-v3 stores, the Profiling System supports multi-values for all data types except longtext and image.
Other Considerations
The following table describes other items you should consider to define effective profile definitions.
| Design consideration | Description |
|---|---|
| Restrictions on WHERE clauses | OLE DB Provider for Commerce Server requires that all properties in the WHERE clauses of queries passed to it map to the same underlying store. This restriction becomes important when you design profile definitions that aggregate data across multiple data objects. |
| Data size limitations | For a detailed description of each of the data types exposed by the Profiling System, see "Profile Definition Components," located in the path “Administering Commerce Server/Running the Profiles Resource/About the Profiles Resource/Profile Definitions/” in Commerce Server 2002 Help. |
| Valid characters in object names | Profile definition object names such as ProfileDefinitionName, ProfilePropertyName, and so on, can contain only alphanumeric characters and the underscore (_) character. |
Copyright © 2005 Microsoft Corporation.
All rights reserved.