Как правильно организовать хранение данных документа в регистре сведений?

← На главную

При разработке систем учета задач или Service Desk в среде 1С часто возникает вопрос: достаточно ли хранить все данные в реквизитах документа или необходимо создавать вспомогательный Регистр сведений? Рассмотрим этот вопрос подробно, проанализируем архитектурные подходы и разберем, как правильно спроектировать структуру регистра для эффективной работы системы.

Зачем нужен регистр сведений, если есть документ?

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

Хранение истории изменений: Документ хранит только текущее состояние. Если вам нужно знать, когда заявка перешла из статуса "Новая" в статус "В работе", вам необходим периодический регистр сведений.
Скорость получения данных: Запросы к виртуальным таблицам регистра (например, СрезПоследних) работают значительно быстрее, чем сложные выборки по документам с группировками по датам.
Изменение данных без перепроведения: Если статус задачи или ответственный меняется в закрытом периоде, редактирование документа может быть запрещено. Независимый регистр сведений позволяет обновлять информацию, не затрагивая сам документ.
Разделение прав доступа: Вы можете ограничить доступ к истории статусов или техническим деталям исполнения через права на регистр, оставляя сам документ доступным для широкого круга пользователей.

Проектирование структуры регистра: Измерения, Ресурсы, Реквизиты

Разберем, как правильно распределить данные по полям регистра на примере задачи управления ИТ-заявками. Рассмотрим структуру, где основным объектом является документ Заявка.

Измерения регистра

Измерения определяют уникальность записи. В 1С нельзя записать две строки с одинаковыми значениями измерений (и одинаковым периодом, если регистр периодический). Рассмотрим ключевые правила:

Основным измерением всегда должен быть ДокументСсылка (тип: ДокументСсылка.ВашДокумент).
Важно: Никогда не используйте строки неограниченной длины в измерениях. На уровне СУБД по измерениям строятся индексы, а индексировать неограниченные строки невозможно. Это приведет к критическому падению производительности.
Измерениями стоит делать только те поля, по которым планируется делать частые отборы (например, Исполнитель или Статус, если вам нужен срез по конкретному статусу).

Ресурсы регистра

В ресурсы мы помещаем данные, которые составляют "содержимое" записи. Это те значения, которые мы хотим получить в результате запроса к регистру.

СтатусЗаявки — если мы отслеживаем текущее состояние.
ОписаниеЗаявки — текстовые данные. Если описание имеет неограниченную длину, его следует размещать именно здесь или в реквизитах.
Ответственный — ссылка на пользователя.

Реквизиты регистра

Реквизиты служат для хранения дополнительной информации, которая не участвует в уникальности и редко используется в отборах, но важна для понимания контекста записи (например, КомментарийКИзменению).

Выбор периодичности и режима записи

Рассмотрим, какой режим записи и периодичность выбрать для системы заявок. Проанализируем два основных варианта:

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

Пример реализации записи в регистр

Рассмотрим программный код для записи состояния заявки в независимый периодический регистр сведений. Это позволяет фиксировать историю переходов между этапами выполнения.


Процедура ЗаписатьСтатусЗаявки(ТекущийДокумент, НовыйСтатус)
    
    МенеджерЗаписи = РегистрыСведений.ИсторияСтатусовЗаявок.СоздатьМенеджерЗаписи();
    
    // Устанавливаем ключ записи
    МенеджерЗаписи.Период = ТекущаяДата();
    МенеджерЗаписи.Заявка = ТекущийДокумент;
    
    // Заполняем ресурсы
    МенеджерЗаписи.Статус = НовыйСтатус;
    МенеджерЗаписи.Исполнитель = ПараметрыСеанса.ТекущийПользователь;
    
    // Записываем данные
    Попытка
        МенеджерЗаписи.Записать();
    Исключение
        Сообщить("Ошибка при фиксации статуса: " + ОписаниеОшибки());
    КонецПопытки;
    
КонецПроцедуры

Как использовать данные регистра в отчетах?

Для получения текущего состояния всех заявок проанализируем работу с виртуальной таблицей СрезПоследних. Это самый эффективный способ узнать, "кто сейчас работает над задачей и в каком она статусе".

Пример запроса на языке 1С:


ВЫБРАТЬ
    ИсторияСтатусовСрезПоследних.Заявка КАК Заявка,
    ИсторияСтатусовСрезПоследних.Статус КАК ТекущийСтатус,
    ИсторияСтатусовСрезПоследних.Исполнитель КАК Исполнитель
ИЗ
    РегистрСведений.ИсторияСтатусовЗаявок.СрезПоследних(&Период, ) КАК ИсторияСтатусовСрезПоследних
ГДЕ
    ИсторияСтатусовСрезПоследних.Статус <> ЗНАЧЕНИЕ(Перечисление.СтатусыЗаявок.Завершена)

Что такое версионирование и стоит ли его использовать?

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

Версионирование: Нужно для аудита ("кто изменил номер телефона в карточке?"). По нему крайне сложно строить аналитические отчеты.
Регистр сведений: Предназначен для бизнес-логики. С его помощью легко построить отчет о среднем времени выполнения задачи или загрузке подразделений.

Итоговые рекомендации

Проанализировав ситуацию, можно сделать следующие выводы для построения качественной архитектуры:

Если вам нужно просто хранить данные, которые никогда не меняются отдельно от документа — используйте реквизиты документа.
Если вам нужна история статусов, быстродействие в отчетах и возможность менять параметры задачи без перепроведения документа в закрытых периодах — обязательно используйте регистр сведений.
В регистре сведений всегда выносите тяжелые данные (длинные строки, описания) в ресурсы или реквизиты, оставляя в измерениях только ссылочные типы для быстрой индексации.
Для систем типа Service Desk рассмотрите возможность использования стандартных объектов Бизнес-процесс и Задача, которые уже имеют встроенную логику переходов и адресации.