При разработке внешних обработок в 1С мы часто сталкиваемся с нестандартными требованиями клиентов. Одно из таких требований — создание табличной части, содержащей 200 колонок на форме. Естественно, возникает вопрос: насколько это реально с технической точки зрения и не приведет ли это к чрезмерной нагрузке на ресурсы компьютера и неудобству для конечного пользователя? Давайте вместе глубоко проанализируем эту ситуацию и рассмотрим все возможные аспекты.
Прежде всего, давайте разберем, что происходит при работе с большим числом колонок в табличной части 1С и какие технические ограничения или особенности мы можем встретить.
Нагрузка на память и процессор. Мы должны понимать, что хотя сама платформа 1С не имеет жестких ограничений на количество колонок в табличной части (максимальное количество строк в табличных частях документов в 1С:Предприятии до версии 8.3.27 ограничено 99 999 записями, а в версии 8.3.27 и выше это ограничение можно увеличить до 999 999 999 записей), большое количество колонок на форме может значительно увеличить нагрузку. Каждая колонка, особенно если она содержит сложные данные или требует вычислений, увеличивает объем данных, передаваемых между клиентом и сервером. При отображении формы каждая колонка требует ресурсов процессора и оперативной памяти для своей отрисовки и управления, что может замедлить работу клиента, особенно на менее производительных машинах.
Особенности работы в веб-клиенте. Мы должны отдельно рассмотреть работу в веб-клиенте. Как упоминалось в одном из сообщений форума, "На вебклиенте могут быть эффекты. Там и так приложение тяжелое, еще и это." (Сообщение 5). Это абсолютно верное замечание. В веб-клиенте проблемы с производительностью могут быть гораздо более выраженными из-за особенностей работы браузеров с большим количеством DOM-элементов. Отрисовка широких таблиц в браузере может быть очень медленной, особенно на маломощных устройствах или при нестабильном интернет-соединении. Для оптимизации отображения больших табличных данных в вебе существуют рекомендации, такие как виртуализация списка (рендеринг только видимой части данных) и уменьшение количества DOM-узлов, но их реализация в 1С может быть ограничена возможностями платформы.
Влияние на сервер базы данных. Давайте проанализируем, как это может повлиять на сервер базы данных. Хотя современные СУБД, такие как MS SQL Server или PostgreSQL, поддерживают большое количество колонок (до 1024 для SQL Server, до 1600 для PostgreSQL в зависимости от типов данных), работа с очень "широкими" таблицами может влиять на производительность запросов. Это особенно актуально, если выборка производится по всем колонкам или требуется сканирование большого количества данных, что может замедлять выполнение операций и увеличивать нагрузку на дисковую подсистему и оперативную память сервера БД.
Оптимизация программного заполнения и запросов. Если мы говорим о программном заполнении такой табличной части, как упомянул автор, "программное заполнение будет идти в цикле" (Сообщение 4). В этом случае критически важна оптимизация запросов к базе данных. Использование неоптимальных запросов, особенно с большим количеством соединений, сортировок или агрегаций по всем колонкам, может значительно замедлить работу и вызвать "зависание" системы, что подтверждает опасения автора о ручном заполнении.
Практический опыт. Важно рассмотреть и практический опыт других разработчиков. Как поделился один из участников форума: "У меня около 150 колонок, особо не тормозит." (Сообщение 6). Этот пример показывает, что в определенных сценариях, при правильной оптимизации и достаточных ресурсах, работа с большим количеством колонок возможна. Однако это не отменяет потенциальных рисков и сложностей, которые мы обсудили.
Мы должны понимать, что техническая реализуемость — это только половина дела. Как клиент будет работать с такой таблицей? Вопрос юзабилити становится здесь ключевым.
Горизонтальная прокрутка и навигация. 200 колонок гарантированно приведут к необходимости интенсивной горизонтальной прокрутки, что крайне негативно сказывается на удобстве использования и читаемости данных. Представьте себе, что пользователю постоянно приходится прокручивать таблицу, чтобы найти нужную колонку или сопоставить данные из разных, далеко расположенных колонок. Это крайне неудобно. Один из участников форума очень точно подметил эту проблему, сравнив ее с абсурдной ситуацией: "Вчера пришёл в магазин, и говорю - хочу кроссовки, где двести дырок для шнурков. Ну и сами шнурки. Меня почему-то послали... Хотя 'покупатель всегда прав'..." (Сообщение 7). Эта метафора ярко демонстрирует, что даже если "покупатель прав" в своем желании, реализация может быть абсурдной и непрактичной с точки зрения здравого смысла и удобства.
Когнитивная нагрузка. Огромное количество информации, представленной на одной форме, увеличивает когнитивную нагрузку на пользователя. Это может привести к частым ошибкам ввода, затруднениям при поиске нужных данных и, как следствие, к снижению общей эффективности работы. Пользователю будет сложно ориентироваться в таком объеме информации.
Целесообразность требования "по максимуму". Мы должны выяснить, почему клиент запрашивает именно 200 колонок. Как было задано в форуме: "Лучше бы написали зачем им 200 колонок а не 182 или 212" (Сообщение 12). Оказывается, "Они не знают, сколько нужно будет точно, и хотят, чтобы хватило по максимуму." (Сообщение 13). Это очень важный момент. Часто требование "по максимуму" означает, что реальная потребность в одновременном отображении всех 200 колонок отсутствует. Скорее всего, пользователям в разные моменты времени нужны разные подмножества данных. Такое требование указывает на необходимость более глубокого анализа бизнес-процессов и сценариев использования.
Сложность разработки и поддержки. "Во внешней обработке [...] будет нагрузка не на компьютер, а на разум клиента и разработчика. Представьте себе, например, кусок кода, который заполняет добавленную строчку." (Сообщение 3). Это справедливое замечание. Поддержка и дальнейшее развитие обработки с таким количеством колонок будет чрезвычайно сложным и трудоемким процессом. Изменения в структуре, добавление новых колонок или изменение логики заполнения будут требовать значительных усилий и увеличивать риски ошибок.
Давайте вместе предложим клиенту более эффективные и удобные решения, которые позволят достичь его целей без ущерба для производительности и юзабилити.
Разделение информации и настраиваемые колонки. Мы должны рекомендовать клиенту разделять данные по сценариям использования и показывать пользователям только ту информацию, которая им необходима для конкретной задачи или их роли. Эффективным решением для форм с большим количеством потенциальных колонок является предоставление пользователям возможности самостоятельно выбирать, какие колонки отображать. Это позволяет каждому пользователю настроить представление данных под свои нужды, уменьшая при этом нагрузку на отрисовку и улучшая читаемость. Для деталей или неоперативных данных лучше использовать отдельные отчеты или формы, а не перегружать основную табличную часть.
Динамическое создание колонок. Если количество колонок действительно динамическое и зависит от данных (например, различные характеристики товаров), мы можем рассмотреть программное создание колонок в ТаблицаЗначений. Это позволяет адаптировать форму под конкретные данные. Однако, это не отменяет проблем с производительностью и юзабилити, если таких колонок все равно будет очень много.
Вынесение редко используемых данных. Для очень больших объемов данных или колонок, которые используются редко, мы можем рассмотреть хранение их в РегистрахСведений или других объектах, подгружая их по требованию или отображая в отдельных, специализированных формах. Это значительно снизит объем данных, обрабатываемых и отображаемых на основной форме.
Использование временного хранилища. Для оптимизации работы с табличными частями, особенно при передаче больших объемов данных между клиентом и сервером, мы можем использовать ВременноеХранилище на сервере для таблиц значений. В этом случае на форме будет храниться только адрес к этому хранилищу, что уменьшит объем данных, передаваемых по сети.
Общая оптимизация платформы 1С. Для ускорения работы с большими таблицами в 1С мы рекомендуем рассмотреть общие подходы к оптимизации платформы. Это включает отключение ненужных фоновых заданий и неиспользуемых модулей, регулярное тестирование и исправление информационной базы, а также работу в режиме тонкого клиента для минимизации нагрузки на клиентский компьютер. Мы должны также следить за состоянием антивируса, который может влиять на производительность.
Оптимизация серверной инфраструктуры. Для высоконагруженных систем мы должны убедиться, что используем клиент-серверную архитектуру. Важен достаточный объем оперативной памяти на сервере 1С и сервере базы данных. Использование высокопроизводительных дисков (SSD/NVMe) для баз данных значительно ускоряет операции ввода-вывода. Также мы должны рассмотреть оптимизацию настроек кластера 1С:Предприятия и SQL Server (или другой используемой СУБД) для обеспечения максимальной производительности.
В конечном итоге, 200 колонок в табличной части, хотя и возможно реализовать технически с определенными оговорками и ограничениями, является крайне неоптимальным решением с точки зрения пользовательского опыта и может привести к значительным проблемам с производительностью и удобством использования.
Мы настоятельно рекомендуем пересмотреть требования клиента, провести более глубокий анализ его бизнес-процессов и предложить более эргономичные и производительные подходы к представлению и работе с таким объемом данных. Наша задача как разработчиков — не просто выполнить требование буквально, а найти оптимальное решение, которое будет эффективно работать и будет удобно для конечного пользователя.