Lesson 4-4

Information registers basics

We use information registers (IR) for a few different purposes.

1. To store data that does not belong to any other metadata object type

In this case, the IR is a closest 1C analogy to the “table” in SQL standard terms. We use it whenever we need just some place to store some general information.

For example, we need to implement a reminder functionality in our system. A user needs to be able to create a short note that will be shown him or other users in a specific moment in future.

Here is an IR we could use for this purpose:

2. To store object’s additional information, we don’t want in a tabular section

Say, we created a document to register invoices we receive by regular mail. We want to store invoice information in document attributes, but we also want to save a scanned image of the original document.

We could create an attribute Image having type ValueStorage in the document itself. But in this case, we would read this image in the memory every time we open the document’s form. To avoid this unnecessary memory usage and possible slowing down of the app we can create the InvoicesImages IR:

3. To set many-to-many relations between objects

Let’s say, we have two catalogs: Students and Courses. Any student may enroll for any number of courses. How do we store this information?

We could use a tabular section of the Students catalog like this:

But what if we need to see all students enrolled for a specific course? To get this data we need to execute this query:

SELECT
	StudentsCourses.Ref.Name,
	StudentsCourses.Ref.Birthday
FROM
	Catalog.Students.Courses AS StudentsCourses
WHERE
	StudentsCourses.Course = &Course

This query gets data from the tabular section using a condition that doesn’t include Ref = &Ref. As we discussed earlier in this Lesson, this query may cause performance problems.

OK, we can replace the tabular section from the Students catalog to the Courses catalog. But what if we want to get all courses the specific student is enrolled for?

Much better solution would be to use this IR:

4. To store a history of some events and get a quick answer to the question “what was first/last value” of some attribute?

We often need to save a story of various events. Here are a few examples:

Currency exchange rates history
Attributes versions history
Log of users activity

Our Prices IR also falls into this category. Let’s consider its structure and features in more details.

IR periodicity

We want an IR to be periodical when we store some kind of history in there. Periodical IRs have a system attribute named Period which contains the point in time this record belongs to. In the examples of IR given above, first three are non-periodic, and the last one is periodic.

Here is a complete list of all periodicity options you can choose from:

You want to use non-periodical IR if you don’t need to bind register’s records to the time axis.

You want to opt for “By recorder position” if the register record has to have the same timestamp as the recorder (a document, that posted the record into the IR).

Below these two you see the list of “Within…” options. Here you need to select how often you want to allow the changes to occur. If you select “Within a day”, you will be able to specify the date of the event but not the exact time of it. What is more important, you won’t be able to add a new record having the same period and the same dimensions as the existing one. You could only rewrite the existing record with the new one (i.e. replace the resources and attributes values).

In other words, an IR secures uniqueness of the records basing on the period (if the IR is periodical) and all dimensions.

What option should we choose here for our Prices IR? Let’s see.

It could be “By recorder position”, meaning that the timestamp of PriceChange document will define the date of the price it sets. So, if we post the PriceChange doc today, the prices it sets will be effective as of today. It looks convenient but at the same time restrain the flexibility of the app. What if we want to change some prices in future? Say, we decided to discount PVC pipes starting from the next month, i.e. timestamps of the document and IR records have to differ.

Therefore “Within…” options (that are independent on the document’s date) seem to be a more reasonable choice.

The only thing we have left here is choosing preciseness of the period. I cannot imagine why would I change the price more often than once a day, so let’s select “Within a day” option.

Lesson 4-3 | Course description | Lesson 4-5

1C:Professional training course. Lesson 4-4