Using chart of characteristic types to implement storage of values related to infobase objects

While designing metadata, you may need to decide between adding attributes and using additional data storage based on a chart of characteristic types.

Let us assume that you need to add some data that describes warehouse properties to a warehouse catalog. For example, you need to store warehouse address for adding it to way-bills handed to forwarding agents. Surely you can do it by adding Address attribute to the warehouse catalog. On the other hand, you can implement additional data storage as an information register or a catalog tabular section using a chart of characteristic types.

These two options are clearly very different, both in implementation details and in the potential use of the resulting solutions.

Adding an attribute is the straightest way possible. This is the closest match to the relational data storage model, it ensures optimal usage of stored data and satisfies the majority of usability requirements. Using an attribute does not require any developer efforts. 1C:Enterprise "knows" how to work with the attribute. It provides support for editing the attribute in forms, displaying it in lists, and accessing it from reports. The platform guarantees the efficiency of operations with the attribute, including search by the attribute. However, if you add the attribute, you have to update all of the forms and reports where you want it displayed. If you add another attribute later, you will need to update the forms and reports again.

If you use a chart of characteristic types instead, you can give users the option to add more types of data that describe warehouses. However, this method requires more developer efforts. In this scenario additional warehouse data is stored in an information register or a tabular section. This does not exactly match the relational data model. Actually, instead of implementing additional fields, you use a table. One of the table fields stores values, while another one stores the data type (for example, Warehouse address or Warehouse size). As 1C:Enterprise cannot automatically determine that this data is related to warehouses, you have to implement operations with this data. This also applies to object input forms, list forms, and any reports based on this data. For example, you might need to describe relations between tables in order to create a report with a filter by a characteristic. The main advantage of this method is the option to add characteristics dynamically, without changing the configuration.

It is hard to decide which method is better. We recommend that you first consider adding an attribute. Use a chart of characteristic types only when you have a reason for this. The main arguments for this option are:

  1. Users need to add characteristics without changing the configuration.
  2. The set of characteristics may vary depending on the object instance.

The first argument is mostly related to standard solutions that are deployed in many companies and often require industry-specific customizations. For example, product characteristics often depend on the product type.

The second argument is relevant when different object instances can have different properties (for example, if a company sells products of different types).

Considering the implementation complexity of the method that involves a chart of characteristic types, we recommend that you set a limit for the total number of its uses in your application. Use this method only when it is necessary to reach the balance between taking advantage of 1C:Enterprise capabilities and reducing solution support costs.

Next page: Using data types for manipulating database objects

Be the first to know tips & tricks on business application development!

A confirmation e-mail has been sent to the e-mail address you provided .

Click the link in the e-mail to confirm and activate the subscription.