Administer > Transforming, loading, and extracting data > Overview of the data load utility > Data load best practices

Catalog: data load best practices

The following best practices are recommended when using the data load utility to load catalog data.

• Catalog

• Catalog Entry

• Catalog Group

• Attribute

• Ensure that you load catalog/catalog group/catalog entry objects to the store which owns the object

  When you are using the data load utility to load the catalog/catalog group/catalog entry objects, make sure that you specify the store which owns those objects in the data load configuration file. When the data load utility creates, replaces or deletes a catalog/catalog group/catalog entry object, the store owner is used to identify the given object to perform the requested operation.

Catalog

• Initialize attribute dictionary

  The attribute dictionary attribute model is more efficient than the classic attribute model. If the store is planning to eventually use attributes, then use the attribute dictionary instead of the classic attributes. The attribute dictionary facilitates data sharing and takes up less number of rows in the database. Specify it in the catalog data load configuration file.

  <_config:property name="initAttributeDictionary" value="true" />
  

Catalog Entry

• Use data load to create parent product before loading the child SKU

  The catalog entry load allows you to create the parent product while creating the child SKUs.

  To improve performance, it is best to use data load to load the specific parent product before loading the child SKUs. By loading the parent product before loading the child SKUs saves the overhead of caching the parent products and related attributes.

• Move a catalog entry from one parent group to another parent group

  To move a catalog entry from one parent catalog group to another parent catalog group, the old parent child relationship needs to be deleted first, then a new relationship can be created. For example. to move the catalog entry with part number 'Test-PN-10001' from category 'Accessory' to 'Pants', two rows are needed in the CSV file:

  PartNumber, ParentGroupIdentifier,    Sequence,    Delete
  Test-PN-10001,    Accessory, 2, 1
  Test-PN-10001,    Pants, 1, 0
  

  The second row deletes the old relationship and the third row adds the new parent child relationship. The data loader configuration for this scenario:

  <_config:mapping xpath="CatalogEntryIdentifier/ExternalIdentifier/PartNumber" value="PartNumber" />
  <_config:mapping xpath="ParentCatalogGroupIdentifier/ExternalIdentifier/GroupIdentifier" value="ParentGroupIdentifier"  /> 
  

• Specify the relationship types when loading the child catalog entries to bundle or kit relationships

  When loading the child catalog entries to bundle or kit relationships, the type of relationship is an optional field in the CSV file. However, it is recommended that you provide this field in the CSV file to optimize data load performance. If this field is not provided, the data load utility retrieves the catalog entry type from the database. Depending on the catalog entry type, the corresponding relationship type is created.

• Use mark for delete option when deleting a catalog entry

  The default behavior for deleting a catalog entry is to mark for delete a catalog entry. This means that the mark for delete flag of this catalog entry in the database is set as '1' and the catalog entry is not physically deleted from the database. Although you can change this default delete option to physically delete a catalog entry, we recommend you to use the default mark for delete option. This is to ensure that any order items which refer to this deleted catalog entry is not removed due to the database cascade delete.

• UserData

  To remove UserData, delete the entire catalog entry that contains the UserData. You can also load blank fields to the UserData tables.

Catalog Group

• Move a catalog group from one parent group to another parent group

  When moving a catalog group from one parent group to another parent group, delete the catalog group from the old parent group before adding it to the new parent group. For example, to move group "Accessory" from old parent group "Womens Fashions" to new parent group "Mens Fashions", two rows need to be specified in the CSV file. The second row deletes the old relationship, and the third row adds the new relationship.

  GroupIdentifier,    ParentGroupIdentifier,    Sequence,    Delete
  Accessory,        Womens Fashions,        2,        1
  Accessory,        Mens Fashions,        3,        0
  

  The data loader configuration for this scenario:

  <_config:mapping xpath="CatalogGroupIdentifier/ExternalIdentifier/GroupIdentifier" value="GroupIdentifier" />
  <_config:mapping xpath="topCatalogGroup" value="TopGroup" />
  <_config:mapping xpath="ParentCatalogGroupIdentifier/ExternalIdentifier/GroupIdentifier" value="ParentGroupIdentifier" />
  <_config:mapping xpath="displaySequence" value="Sequence"  />
  <_config:mapping xpath="" value="Delete"  deleteValue="1"/>
  

• Multiple languages

  Even though data load supports loading catalog groups with multi-language descriptions in one CSV file, it is recommended to load each language in its own CSV file. This is because the CSV file for different languages can use the different encoding setting, and it is easy to manage. For example, double byte languages like Chinese have different encoding settings.

Attribute

• Use attribute dictionary for attributes

  The attribute dictionary attribute model is more efficient than the classic attribute model. If the store is planning to eventually use attributes, then use the attribute dictionary instead of the classic attributes. The attribute dictionary facilitates data sharing and takes up less number of rows in the database.

• Load attributes and allowed values together

  Attributes and allowed values can be loaded together or separately. For simplicity and manageability, it is recommended to load them together in one CSV file. The separate attribute value load is intended for more granular loading and should be only used when load details (such as Field1, Field2, Field3, Image1, Image2) for each individual attribute value.

• Load catalog entry and attribute relationship

  After you load the attributes and allowed values into the attribute dictionary, load the relationship between the product SKU item and the attribute value directly. The relationship between product and attribute is automatically handled by the data load mediator.

Related tasks

Examples: Mapping pricing data

Examples: Mapping inventory data

Related reference

Inventory: data load best practices

Price: data load best practices

Examples: Mapping catalog data

+

Search Tips   |   Advanced Search