Часто при интеграции со сторонними системами возникает задача регулярного импорта больших объемов информации. Проанализируем типичную ситуацию: каждые полчаса в базу загружается 2500 и более строк, каждая из которых содержит 25+ полей. Иногда данные полностью идентичны предыдущей загрузке. Если попытаться сохранить всё это в табличную часть одного документа, мы столкнемся с серьезными проблемами: интерфейс превращается в нечитаемое месиво, база данных стремительно разрастается, а производительность падает. Рассмотрим по шагам, как грамотно организовать структуру хранения и отображения таких данных в 1С.
Использование документа в качестве простого буфера для приема тысяч строк — это классический архитектурный антипаттерн в 1С. Документ задуман как объект для фиксации конкретных хозяйственных операций, а не как шлюз для интеграции. Разберем подробнее, почему лучше использовать независимые регистры сведений.
Рекомендуется не загружать "лишний хлам" в 1С через громоздкие табличные части, а писать данные напрямую в Независимый регистр сведений. Если загружаемые данные содержат текстовые идентификаторы, которые нужно связать со справочниками (например, контрагентами или номенклатурой), сопоставление следует выполнять в оперативной памяти сервера с использованием объекта Соответствие или заранее закешированных таблиц. В сам регистр записываются уже готовые ссылки.
Если данные вообще не требуют ссылочной целостности и служат только для логгирования, есть смысл рассмотреть их хранение во внешней базе данных, обращаясь к ним из 1С только по мере необходимости.
Так как данные могут приходить без изменений, нам необходимо отсекать лишние операции записи. Выясним причину проблемы: постоянная перезапись одинаковых данных раздувает журнал транзакций СУБД и тормозит систему. Решить это можно несколькими путями.
Слияние и Обновление для наборов записей регистров.Посмотрим на пример использования платформенного механизма замещения при записи в регистр:
НаборЗаписей = РегистрыСведений.ЗагруженныеДанныеИнтеграции.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Период.Установить(ТекущаяДата());
// Заполнение набора новыми данными...
НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.Поле1 = Значение1;
// Запись с использованием режима слияния (платформа сама обновит только измененные строки)
НаборЗаписей.Записать(Истина, РежимЗамещенияОбновлениеЗаписей.Слияние);
Если сырые данные требуются для истории, аудита или расследования инцидентов, совершенно необязательно создавать под них огромную структуру метаданных. Исходный пакет (JSON, XML или CSV) целесообразно сохранять в базу в сжатом виде, используя тип данных ХранилищеЗначений.
При таком подходе мы парсим данные один раз — нужные для оперативной работы значения сразу пишутся в регистр, а сам исходный файл компактно ложится в реквизит с типом ХранилищеЗначений. Извлекать и показывать эти данные пользователю можно только по требованию (по нажатию специальной кнопки).
Разберем ситуацию, когда пользователю действительно нужно просматривать и анализировать этот огромный массив. Открывать документ с табличной частью на 25+ полей — это плохой пользовательский опыт. Колонки не помещаются на экран, появляются бесконечные горизонтальные прокрутки. Существует несколько способов организовать интерфейс более элегантно:
ПолеHTMLДокумента. Средствами веб-технологий можно отрисовать красивую таблицу с замороженными колонками и подсветкой изменений между загрузками.При загрузке 2500 строк каждые полчаса важно помнить про оптимизацию серверных вызовов и блокировок. Не пытайтесь записывать все данные построчно в цикле — это крайне медленно. Также опасно пытаться записать огромный массив данных одной гигантской транзакцией.
Рассмотрим правильный подход: разбивайте загружаемый массив на порции (например, по 500 или 1000 записей) и выполняйте запись наборов данных пакетами. Это обеспечит оптимальный баланс между скоростью работы базы данных 1С и нагрузкой на оборудование, а также снизит вероятность таймаутов на блокировках при многопользовательской работе.