Share via


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

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

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.