В практике разработки на платформе 1С:Предприятие 8.3 часто возникают задачи по созданию документов с огромным количеством строк. Когда их число переваливает за 10 000 – 20 000, стандартные механизмы работы с табличными частями начинают давать сбои: форма «зависает» при открытии, поиск работает медленно, а RLS превращает проведение документа в мучительное ожидание. В этой статье мы подробно проанализируем, какой подход выбрать — классическую табличную часть или использование регистров сведений напрямую — и как обеспечить высокую производительность системы.
Рассмотрим, что происходит внутри платформы, когда мы открываем форму документа с табличной частью в 20 000 строк. При каждом серверном вызове (например, при нажатии кнопки, требующей контекста формы) система выполняет сериализацию: упаковывает все данные формы, включая эти 20 000 строк, в XML или JSON, передает их между клиентом и сервером, а затем распаковывает обратно.
Даже если пользователь изменил всего одну строку, платформа вынуждена «прокачивать» через сеть весь массив данных. Это приводит к следующим последствиям:
Проанализируем ситуацию с точки зрения безопасности. Если в системе настроен RLS, то фильтрация данных в табличной части документа происходит значительно сложнее и медленнее, чем в регистрах. Система вынуждена анализировать права на лету при чтении объекта. В случае с Регистром Сведений (РС) механизмы RLS работают нативно на уровне SQL-запросов, что позволяет базе данных эффективно отсекать ненужные записи еще на этапе выборки.
Важный момент: Если пользователь с ограниченными правами откроет документ с огромной табличной частью, в которой часть данных ему недоступна, при записи документа может возникнуть коллизия — либо затирание «невидимых» данных, либо ошибка доступа. Работа через регистр сведений (независимый или подчиненный регистратору) позволяет избежать этих проблем за счет более гранулярного управления доступом.
Самый эффективный способ реализовать интерфейс «все видеть и все править» при большом объеме данных — это использование Динамического списка. Разберем этот метод по шагам:
Преимущества: Данные подгружаются порциями по мере прокрутки (пейджинг). Поиск и фильтрация выполняются средствами SQL-сервера по индексам регистра, что происходит практически мгновенно. Мы не перегружаем контекст формы лишними данными.
Посмотрим на вариант, когда данные отображаются через набор записей регистра, подчиненного документу. Этот метод часто используется в документе ОперацияБух. Рассмотрим пример кода, как можно программно управлять записью таких данных:
// В модуле формы или документа
Процедура ЗаписатьДвиженияРегистра(Отказ)
НаборЗаписей = РегистрыСведений.НашРегистрДанных.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(ЭтотОбъект.Ссылка);
// Вместо обхода всей ТЧ формы, мы можем работать с данными непосредственно в базе
// или передавать только измененные строки
НаборЗаписей.Записать();
КонецПроцедуры
Однако стоит помнить: размещение Объект.Движения.ИмяРегистра непосредственно на форме в виде таблицы также создает нагрузку на контекст формы, аналогичную табличной части, если выводить все строки сразу. Чтобы этого избежать, лучше использовать АРМ (Автоматизированное рабочее место).
Если бизнес-процесс требует сложной логики (например, пересчет по формулам для 20 000 строк), рекомендуется разделить процесс на «просмотр» и «редактирование». Рассмотрим схему работы эффективного АРМ:
Такой подход используется в типовых конфигурациях, например, в 1С:Управление торговлей 11 при работе с ценами номенклатуры. Там документ является лишь «фиксатором» изменений, а сама работа ведется в специализированном рабочем месте.
Выясним причину, по которой документы с огромными ТЧ быстро увеличивают размер базы данных. Если в системе включено Версионирование объектов (БСП), то при каждом сохранении документа создается полная копия всех его данных. Если документ на 20 000 строк будет пересохранен 10 раз в процессе согласования, система сохранит 200 000 записей в таблице версий.
Рекомендация: При использовании регистров сведений лучше задействовать платформенный механизм История данных (появился в версии 8.3.11). Он работает гораздо тоньше: логирует изменения только конкретных измененных записей регистра, а не всего массива данных документа целиком. Это существенно экономит место на диске.
Проанализировав ситуацию, можно сделать следующие выводы:
Такой подход обеспечит масштабируемость системы и позволит пользователям комфортно работать с большими массивами данных без раздражающих задержек.