← На главную

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

Проблема прямого чтения табличных частей документа

На первый взгляд кажется, что создание регистра накопления с теми же реквизитами, что и в табличных частях (ТЧ) документа, — это избыточное дублирование информации. Однако обращение к табличным частям документа в аналитических отчетах несет в себе ряд серьезных технических ограничений:

1. Особенности физической структуры хранения и индексации. В реляционной СУБД табличная часть документа хранится в отдельной таблице. Кластерный индекс этой таблицы всегда строится по полям Ссылка и НомерСтроки. В таблице ТЧ физически отсутствует дата документа. Чтобы отобрать записи за период, СУБД вынуждена выполнять соединение (JOIN) с таблицей шапки документа. Если в ТЧ отсутствуют специализированные индексы по аналитическим полям, построение выборки приводит к операциям полного сканирования таблицы (Table Scan или Index Scan), что кардинально замедляет выполнение отчетов при росте информационной базы.
2. Сложность соединения нескольких табличных частей. Если документ содержит две связанные табличные части, для получения итоговых данных в отчете потребуется использовать сложные конструкции запросов (полные соединения ПОЛНОЕ СОЕДИНЕНИЕ, вложенные запросы или группировки). Это создает дополнительную вычислительную нагрузку на процессор и оперативную память сервера СУБД при каждом формировании отчета пользователем.
3. Ручной контроль статуса документа. При выборке напрямую из табличных частей разработчик обязан в каждом отчете вручную отслеживать флаги Проведен = Истина и ПометкаУдаления = Ложь. Ошибка в условиях выборки приведет к искажению аналитических данных.

Преимущества использования оборотного регистра накопления

Оборотный регистр накопления решает описанные проблемы за счет механизмов оптимизации и предрассчитанных итогов:

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

Параллельность работы и блокировки

Проанализируем работу системы при одновременной работе нескольких пользователей. Для оборотного регистра накопления доступна опция «Разрешить разделение итогов». Данный механизм предотвращает взаимоблокировки (deadlocks) в СУБД при параллельном проведении документов несколькими пользователями, распределяя записи итогов со смещением.

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

Ограничения и регламентное обслуживание

Использование оборотного регистра накопления накладывает определенные требования к администрированию системы:

1. Накладные расходы при проведении. Запись движений требует дополнительных операций СУБД при проведении документа: вставки в таблицу движений и обновления агрегатов в таблице итогов.
2. Актуализация рассчитанных итогов. Для стабильной производительности виртуальной таблицы Обороты необходимо настроить регламентное задание пересчета итогов или использовать метод:
   Скопировать код

   
   РегистрыНакопления.ИмяРегистра.УстановитьПериодРассчитанныхИтогов(КонецМесяца(ТекущаяДата()));
   

   Если граница рассчитанных итогов отстает от текущего периода, виртуальная таблица теряет преимущества кэширования и начинает рассчитывать обороты «на лету» по таблице движений.

Когда регистр накопления не требуется

Прямые запросы к табличным частям документа оправданы в ограниченном числе сценариев:

1. Формирование контекстных печатных форм конкретного документа.
2. Интерактивные проверки заполнения полей на форме документа при вводе данных.
3. Служебные отчеты для администраторов по контролю заполнения реквизитов в непроведенных документах.

Если же по данным предполагается строить регулярные сводные отчеты, графики, панели показателей или фильтровать информацию за произвольные периоды времени, создание оборотного регистра накопления является единственно верным архитектурным решением.