Developing a periodic information register structure





One of the most common use cases for periodic information registers is storing the change history of some object-related data. When information registers are designed, the most complicated question is how to reflect data from a certain subject area in the structure of these registers.

1C:Enterprise 8 information register can contain multiple dimensions, resources, and attributes. A common question is how many information registers are needed to store several values that change with time. You can create a single register with several resources to store all values at once, or you can create several registers, each with a single resource that stores a single value.
Each information register is a standalone table. Each entry of a periodic register contains information about the values of certain resources by a certain combination of dimensions within a certain period of time. Each resource value is recorded explicitly and takes effect at the specified time. A register record cannot state that the value is not changed. When a slice of a register (a set of resource values at certain time) is requested, the platform searches for the latest entries by a combination of dimensions and returns the resource values that are found.

There is no uniform rule on how to design registers, i.e., "create one register" or "create many registers". When you design a periodic register, proceed from the assumption that each entry should reflect the fact that the values for all the resources as of a specific moment of time have been set in a database. Note that the register entry will reflect the fact that the user has set values for all the resources regardless of their previous values.

When you design a register, you need to analyze how values actually change with time and develop a model to reflect these value changes in a database. It is very important that the user understands how a subject area is reflected in an information register. This determines whether a register is used correctly.

Let us review a very common example of a register that stores exchange rates. You need to store the exchange rate and conversion factor for each currency. You can create two registers: one for storing the history of exchange rate changes, and another for stroing the history of conversion factor changes. On the other hand, you can create a single register where each entry stores both the exchange rate and conversion factor. Obviously, the conversion factor will change much less often. A single register is easier to implement, and it is more user-friendly. Both options are possible. In the first one setting the exchange rate and setting the conversion factor are treated as separate actions. Of course they can be edited in a single form and written as a single document, but you have to ensure that a user looking at the register lists understands that the change histories are stored separately. In the second possible scenario setting the exchange rate and setting the conversion factor are treated as a single action. When a new exchange rate is set, a new conversion factor value must also be set. Of course you can implement filling the conversion factor with the previous value during the record creation, so that users do not have to enter it every time. It is important to ensure that users who create records or view the record list understand that each entry sets both values and they take effect at the specified moment.

In some scenarios several values are closely connected to each other, and there is no reason to keep separate change histories. For instance, as a general rule, all pieces of passport data (series, number, date of issue, etc.) change at once. The values included in the change history can be united to reduce the number of independently stored histories (as is the case with the exchange rate and conversion factor). We recommend that you unite histories when you need to store a large number of values. It is a good idea to group values based on their meaning. It is also very important to present this grouping visually to the user. For instance, if you create a periodic information register to store the price of an item and a standard discount, the record editing form (or the form used to edit the document that generates the information register records) should state that a new price and a new discount take effect on the specified date.

Note that grouping several values into a single information register makes sense, and not only because it reduces the number of tables and increases performance. In general, it is more convenient to deal with a single action of changing several values than with multiple histories.

Another aspect to consider when you are designing information registers is the ability to introduce new dimensions. For instance, if you store prices of goods in a periodic information register, you can later introduce a new dimension (i.e., a price type) to store several prices with user-defined types. However, you need to keep this option in mind when designing the register structure. In particular, this can be used as a criterion that defines whether several change histories can be grouped into a single register. If introducing new dimensions will require you to divide the register, it makes more sense to create two registers from the beginning. For example, uniting prices and minimum stock reserve in a single register is not the best option.

Since an information register is a single table in a database, it is very easy to evaluate the advantages and disadvantages of different register structures from the performance perspective.

A large number of information registers can impact the performance in scenarios where you need to obtain object data and data from periodic registers related to that object and having a specific time stamp. It is obvious that you can obtain a slice from a single register with a large number of resources a lot faster.

Writing a single record with multiple resources is also faster than writing to several information registers.

If you expect a large number of records that reflect frequent changes of a single resource value, the database grows faster when the register has multiple resources. This can significantly affect the database size, especially if one of the resources is a value storage that stores an image or some binary data. We recommend that you store such data in a separate register.


Comments
0
Add comment