List of things to consider when designing your catalog schema.
 
  1. Since a property in the catalog system translates to a column in a sql server table you should  restrict the number of properties in your catalog system. This can be achieved by sharing the properties across product and category definitions. For eg instead of creating separate properties for category and product descriptions you can create just one property named Description and reuse it in the category and product definitions.
  2. Identify and define the multilingual properties. Consider creating a property as a multilingual property only if the property will contain values in multiple languages.
  3. If you have to use a lot of string properties with significant lengths , consider using the text datatype instead of string datatype.
  4. In order to have a truly multilingual experience, define display names for all your properties in the languages you are planning to support.
  5. Ensure that all the properties have appropriate default values (to minimize data entry during product and category creation) and that they have minimum and maximum constraints defined on them as appropriate.
  6. Consider creating an enumeration property instead of string property if the value for the property will come from a fixed set of values. For eg a Color property which accepts Red, Green and Blue values only can be created as an enumeration property instead of a string property.
  7. Define appropriate enumeration values for all the enumeration properties. For multilingual enumeration properties ensure that the enumeration values are defined in all the languages you are planning to support.You can also select one of the enumeration value as the default value for that property.
  8. Identify and define the freetextsearchable properties. Define a property as freetextsearchable only if the contents of that property will contain relevant keywords to locate a product or category. Consider minimizing the number of freetextsearchable properties by sharing freetextsearchable properties across definitions. A preferred solution would be to create just a single multilingual property (for eg keywords) as a freetext searchable property and have it contain all the search keywords for products and categories in the supported languages. For each product or category set the value of the keywords property to the relevant keywords for that item.
  9. If you are using the Commerce Server Feature Pack (which you should by now), do not create a separate property for storing display names for products and categories.The catalog system has a built in property named DisplayName which stores the display names for products and categories. If you have upgraded to the Feature Pack,  then use the migration tool to migrate to the built in display name property for products and categories.If you are still running CS2002 SP2 or an older version, consider upgrading to the Commerce Server Feature Pack.
  10. If you are intending to use the Specification Search feature, identify and mark the IncludeInSpecSearch attribute for the relevant properties. Mark a property specification searchable only if its value describes a feature specification of a product. For eg. the property Printing Technology defines a feature of a printer and can be marked specification searchable.
  11. Identity and define all the properties which should have a non-null value in a product or a category and set the IsRequired attribute for these properteis to true. The UI will then ensure that the user enters a valid value for that property when creating a product or a category.
  12. If a particular property should appear in all the product definitions, then set the AssignAll attribute to true. If you are creating definitions using Business Desk, then it will ensure that this property will be automatically added to any new product definition. Note that this functionality is provided by Business Desk only and not by the catalog system.
  13. Create your category and product definitions. When adding properties to a definition consider sharing them across definitions to minimize the number of properties in the catalog system and improve performance and reduce maintenance.
  14. When creating a product definition, consider if the purpose of the definition is to create products or product families and variants. If the definition should create products then add all the properties as normal properties. If the definition should create product families and variants, then identify the normal and variant properties in the definition and add them as appropriate. See this link for an understanding of products and product families.
  15. If necessary, order the properties in your definition. This can be done using Business Desk or programatically.The order of the properties can be useful when you present the UI for editing products and categories. The order of the properties in the definition can define the order the properties are displayed to the user for data editing.