← На главную

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

Давайте вместе разберемся в механизмах платформы 1С и рассмотрим несколько эффективных подходов к решению этой задачи.

Причина медленной работы: как 1С загружает данные документа

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

Процесс открытия формы объекта можно разделить на два ключевых этапа:

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

Таким образом, даже если ваши служебные ТЧ скрыты, они все равно тратят время на чтение из базы данных. Но основной удар по производительности, который ощущает пользователь (особенно при работе через веб-клиент или медленное соединение), наносится при передаче этих больших объемов данных между сервером и клиентом.

Решение 1: Оптимизация клиент-серверного обмена через свойство «Использовать всегда»

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

Как это работает?

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

• Данные этой ТЧ по-прежнему будут прочитаны из базы данных в объект на сервере (на этапе 1).
• Однако эти данные не будут автоматически передаваться на клиент при открытии формы и последующих серверных вызовах.

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

Разберем по шагам, как это настроить:

1. Откройте конфигуратор и найдите нужный вам документ.
2. Перейдите на вкладку «Данные».
3. Найдите в списке реквизитов вашу служебную табличную часть.
4. Выделите ее и откройте палитру свойств (правой кнопкой мыши -> Свойства).
5. В свойствах найдите группу «Использование» и свойство Использовать всегда.
6. Измените его значение на «Нет».

Важное ограничение: После отключения этого свойства вы больше не сможете обратиться к данным этой ТЧ напрямую на клиенте. Попытка прочитать Объект.МояСлужебнаяТЧ в клиентском коде вернет пустую таблицу, так как этих данных на клиенте просто нет. Это идеальный сценарий для нашего случая, когда данные нужны только на отдельной форме, открываемой по кнопке. При открытии этой вспомогательной формы вам нужно будет сделать серверный вызов, который получит данные из серверного объекта (Объект.МояСлужебнаяТЧ) и вернет их на клиент для отображения.

Решение 2: Перенос данных в подчиненные регистры сведений

Это более кардинальный подход, который был предложен в самом начале обсуждения. Он заключается в том, чтобы полностью убрать служебные ТЧ из структуры документа и перенести их данные в один или несколько регистров сведений, подчиненных документу-регистратору.

Проанализируем плюсы и минусы этого решения.

Плюсы:

• Максимально «легкий» объект документа. Сам документ будет содержать минимум данных, и его чтение из базы будет происходить практически мгновенно.
• Отложенная загрузка (Lazy Loading) по умолчанию. Данные из регистров будут запрашиваться только тогда, когда они действительно нужны — например, при нажатии кнопки для открытия формы с историей.
• Гибкость анализа. Данные в регистрах сведений гораздо удобнее анализировать с помощью запросов для построения отчетов, в отличие от данных в табличных частях.

Минусы:

• Усложнение логики. Вам потребуется написать дополнительный код для записи данных в регистры при проведении или записи документа. Также нужно будет обрабатывать ситуации отмены проведения.
• Увеличение количества запросов к БД. Вместо одного запроса на чтение всего документа, у вас будет один запрос на чтение основной части и затем еще один (или несколько) для получения данных из регистров. Это не всегда плохо, но требует внимания.
• Усложнение структуры метаданных. Вместо одного объекта-документа у вас появляется связка «документ + регистры», что может сделать конфигурацию менее наглядной.

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

Решение 3: Альтернативные варианты хранения

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

Хранение данных в реквизите типа «ХранилищеЗначения»

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

• Преимущество: С точки зрения СУБД, вместо 10 таблиц с тысячами строк у вас будет всего одно поле в основной таблице документа. Чтение такого объекта будет очень быстрым.
• Недостаток: Данные становятся непрозрачными для базы данных. Чтобы получить к ним доступ, нужно сначала прочитать объект, извлечь данные из хранилища и десериализовать их. Поиск или фильтрация по этим данным средствами запросов невозможна.

«Ленивая» загрузка данных из ТЧ по запросу

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

Алгоритм такой:

1. На основной форме документа есть кнопка «Показать историю».
2. При ее нажатии выполняется серверный вызов.
3. На сервере выполняется запрос, который обращается напрямую к таблицам СУБД, соответствующим табличным частям документа (например, Документ.ИмяДокумента.ИмяТЧ), с отбором по ссылке на текущий документ.
4. Полученные данные возвращаются на клиент и отображаются в динамически открытой форме.

• Преимущество: Это самый «чистый» способ с точки зрения производительности основной формы. Она вообще ничего не знает о тяжелых данных до тех пор, пока пользователь их не запросит.
• Недостаток: Требует больше ручного программирования для организации запроса и отображения данных.

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

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

• Если вам нужно быстрое и простое решение для ускорения отзывчивости формы, начните со свойства Использовать всегда = "Нет". В 90% случаев этого будет достаточно.
• Если чтение самого объекта на сервере занимает слишком много времени из-за гигантского объема данных в ТЧ, рассмотрите перенос данных в регистры сведений. Это более сложный, но и более масштабируемый подход.
• Если служебные данные не нужны для отчетов и являются просто «снимком» состояния, хорошей альтернативой может стать ХранилищеЗначения.
• Если вы стремитесь к максимальной производительности и готовы писать больше кода, реализуйте «ленивую» загрузку данных по запросу.

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