Как правильно выбрать структуру регистра сведений в 1С?

Проектирование структуры регистра сведений (РС) — это одна из базовых, но в то же время ответственных задач при разработке в системе 1С:Предприятие 8. Ошибки на этом этапе могут привести к невозможности хранения нужных данных, дублированию записей или крайне низкой производительности отчетов. Разберем подробно, чем руководствоваться при определении состава измерений, ресурсов и реквизитов.

Основополагающая логика: Измерения, Ресурсы и Реквизиты

Прежде чем приступать к созданию объекта в конфигураторе, проанализируем природу данных. В 1С регистры сведений относятся к необъектным сущностям. В отличие от справочников или документов, запись регистра не имеет уникальной ссылки (UUID), по которой к ней можно обратиться. Уникальность записи определяется ключом записи.

Рассмотрим, как распределяются роли полей:

1. Измерения: Это «разрезы» хранения информации. Совокупность всех измерений (а также периода для периодических регистров и регистратора для подчиненных регистров) формирует уникальный ключ. Если вы попытаетесь записать строку с тем же набором измерений, система либо перезапишет старую запись (в непериодическом регистре), либо выдаст ошибку. По измерениям 1С автоматически строит индексы в базе данных SQL, что обеспечивает быстрый поиск.
2. Ресурсы: Это целевые данные, которые мы храним в разрезе измерений. Именно ресурсы мы планируем получать в отчетах или использовать в методах СрезПоследних() и СрезПервых().
3. Реквизиты: Это дополнительная описательная информация. Они не влияют на уникальность и не участвуют в механизмах срезов. Реквизиты нужны для хранения служебных данных, которые «сопровождают» запись, но по которым не требуется выполнять высокоскоростной поиск.

Практический кейс: Система комментариев к бизнес-процессу

Рассмотрим ситуацию: нам необходимо хранить комментарии пользователей, привязанные к пунктам и этапам бизнес-процесса. Процесс может иметь несколько итераций (этапов), а по каждому пункту может быть оставлено несколько комментариев. Выясним, как спроектировать такой регистр.

Проанализируем требования к полям:

• Бизнес-процесс (ссылка).
• Этап (число — номер итерации).
• Пункт (элемент справочника).
• Автор (пользователь).
• Дата комментария.
• Текст комментария.
• Признак «Проверено».
• Номер строки (для сортировки в отчете).

Формирование ключа уникальности (Измерения)

Выберем те поля, которые определяют уникальность записи. Если мы сделаем измерениями только БизнесПроцесс и Этап, то система позволит сохранить только один комментарий на весь этап. Но нам нужно хранить разные комментарии по разным пунктам и авторам.

Рекомендуемая структура измерений:

1. БизнесПроцесс: Обязательное измерение. Установим для него свойство Ведущее. Это гарантирует, что при удалении объекта бизнес-процесса все записи в регистре по нему очистятся автоматически.
2. Этап: Разрез, в котором фиксируются данные.
3. Пункт: Конкретизация места комментария.
4. НомерСтроки (или КлючСвязи): Важный момент. Если пользователь может оставить два разных комментария по одному и тому же пункту в рамках одного этапа в одну и ту же секунду, нам нужно поле, которое сделает эти записи уникальными. Числовое поле «Номер строки» отлично справится с этой ролью в качестве измерения.

Определение хранимых данных (Ресурсы и Реквизиты)

Теперь определим, что является результатом записи, а что — справочной информацией.

Ресурсы:

• Комментарий: Хотя это может быть строка неограниченной длины, в данном случае это основная информация, которую мы хотим извлекать.
• Проверено: Булево значение, которое удобно использовать в фильтрах отчетов. Если мы хотим быстро получать список непроверенных комментариев, это поле должно быть ресурсом.

Реквизиты:

• Автор: Если нам не нужно получать «последнего автора» через срез, а достаточно просто знать, кто создал конкретную запись, это поле лучше вынести в реквизиты.
• ДатаСоздания: Служебная информация о моменте записи.

Технические тонкости использования типов

Проанализируем влияние типов данных на производительность. Использование Строки неограниченной длины в измерениях недопустимо — это приведет к невозможности индексации и критическому замедлению системы. Такие строки всегда должны быть либо ресурсами, либо реквизитами.

Для работы с регистрами во встроенном языке мы используем менеджер регистра. Рассмотрим пример записи данных в созданную нами структуру:

МенеджерЗаписи = РегистрыСведений.КомментарииБизнесПроцессов.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Период = ТекущаяДата();
МенеджерЗаписи.БизнесПроцесс = ВыбранныйБП;
МенеджерЗаписи.Этап = НомерИтерации;
МенеджерЗаписи.Пункт = ТекущийПункт;
МенеджерЗаписи.НомерСтроки = НоваяСтрока; // Обеспечиваем уникальность

МенеджерЗаписи.Комментарий = "Текст отзыва пользователя";
МенеджерЗаписи.Проверено = Ложь;
МенеджерЗаписи.Автор = ПараметрыСеанса.ТекущийПользователь;

МенеджерЗаписи.Записать(Истина); // Истина — для замещения существующей записи с таким ключом

Периодичность регистра

Если бизнес-требование звучит как «нам нужна история изменений», регистр обязательно должен быть периодическим. В этом случае платформа автоматически добавит поле Период в ключ уникальности. Это позволяет хранить разные состояния одних и тех же измерений в разные моменты времени.

Выясним разницу в использовании периодичности:

• В пределах секунды: Стандарт для большинства бизнес-задач.
• В пределах дня: Позволяет хранить только одно состояние данных на дату. Повторная запись в этот же день перезапишет предыдущую.

Посмотрим, как это влияет на выбор структуры. Если регистр периодический («В пределах секунды»), то поле Период само по себе обеспечивает уникальность в рамках времени. Но если в одну секунду может произойти несколько событий (например, массовая загрузка комментариев роботом), одного Периода будет недостаточно, и нам снова потребуется дополнительное измерение для обеспечения уникальности ключа.

Резюме по выбору структуры

При проектировании любого регистра сведений мы рекомендуем придерживаться следующего алгоритма:

1. Выделите все поля, по которым будет выполняться фильтрация в отчетах. Это кандидаты в измерения.
2. Проверьте, обеспечивают ли выбранные измерения уникальность. Если возможны дубли в рамках одной комбинации — добавьте техническое измерение (код, номер строки, GUID).
3. Определите «Ведущее» измерение. Обычно это основной объект, к которому «привязан» регистр.
4. Данные, которые являются ответом на запрос (статусы, суммы, тексты), поместите в ресурсы.
5. Всю второстепенную информацию (кто записал, когда, из какого узла обмена) вынесите в реквизиты.

Правильно спроектированная структура — это залог того, что ваши отчеты будут работать быстро, а данные в базе останутся целостными даже после удаления связанных объектов.