The dynamic nature of classification features means they’re never guaranteed to be present for any given product. Therefore, they shouldn’t be part of any business logic, price or discount calculations, or the fulfillment process. Instead, classification features should solely be used for informational purposes; for example, to provide technical product specifications.
You should also keep in mind that the complexity of assigning features from the classification catalog to products in the product catalog can degrade performance.
Multiclassification is also supported: A regular category can be classified by more than one classifying category.
Note
Please remember: When a category is directly classified, it loses all inherited classification features.The value of a category feature can optionally be assigned a classification unit, such as volt, or cubic centimeter, used to put the classification attribute’s value in context. This unit is specific to the classification system and shouldn’t be confused with the units assigned to products; those determine how the product’s quantity should be interpreted, and can have values such as pieces, dozens, spools, and so on.
Therefore, category units can only be assigned to category features, and product units to products.
Classification Versus Type System
Product features are derived from classification categories inside a classification system. This system is managed in the classification catalog, which is also persisted in the database.
Product attributes in the Type System are defined in the items.xml configuration file, which is consulted when building the commerce system.
Each approach to add properties to products has advantages and drawbacks.
- Product attributes are more efficient and easier to manage by the system because of the direct mapping to the data model API and the corresponding database tables. Conversely, product features incur a performance cost because they’re fetched from the Classification System, which involves more complex resource management.
- Product features can be defined in Backoffice at runtime. As a result, no developer involvement, system rebuild or system update are necessary. Conversely, changes to the Type System require a rebuild, restart, redeployment, and a system update.
Using product attributes and product features in Flexible Search queries:
- Since product features are dynamically defined at run time, access via the API or by using Flexible Search queries incurs a performance cost for the logic needed to handle attempts to refer to nonexistent data.
- As product attributes are statically defined in the Type System, they're known at build time and are safe to use in a Flexible Search query.
Classifications Versus Type System – When to Use What?
Recommendations:
- Product features should be used in situations in which they are only temporarily assigned to products or as properties that are only shared by a small range of products.
- Product attributes should be used when they are:
- Permanently shared by a large number of products, such as code, height, or width.
- Used in business logic such as service execution, searches, and the fulfillment process.
- Used as Item references, for example, a reference to a Media Item used to illustrate the product.
The following table summarizes the described differences between the type and classification system:
Type System Versus Classification
| Criteria | Type System | Classification |
|---|---|---|
| Character | Basic Method | Advanced method |
| Use Case | Static product attributes used in the business logic | Recommended for changeable product attributes that are not to be used in business logic. Used for attributes that must be created at runtime. |
| Applicable to | All data types | Products only |
| Scope | All instances of a type | Regular categories or selected individual products |
| Performance Implication | Less load on the database | More load on the database and more complex resource management |
| Typical User | Developer | Product Manager, Marketing Manager |
| Modification | Complex adaptation to new requirements by coding | Flexible adaptation in Backoffice at runtime or by CSV import |
| Outcome | Type attribute | Feature for product, also referred to as classification attribute/feature |
| Technique | A type attribute is defined in the code, becomes part of every item of this type and can be used for business logic | A category feature is defined in Backoffice as part of a classifying category and will only affect direct or indirect classified products. Features will not become part of the type and its items, thus not usable for business logic |
| Restriction | No multi-inheritance, no retyping | Multiclassification of categories/products is supported. Unclassification is also possible anytime |