← На главную

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

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

Анализ самописного пореквизитного хранения (модель EAV)

Рассмотрим распространенную идею: создать периодический регистр сведений со структурой измерений и ресурсов: Период, Ссылка (измерение), ИмяРеквизита (измерение/ресурс), ЗначениеРеквизита (ресурс), Пользователь (ресурс).

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

1. Сложность работы с табличными частями: если в справочнике или документе изменяются строки табличных частей, для сохранения плоской таблицы потребуется существенно усложнять структуру регистра (добавлять измерения ИмяТабличнойЧасти, НомерСтроки, ИмяКолонки), что делает запись и чтение чрезвычайно громоздкими.
2. Нагрузка на СУБД и производительность: при изменении одного объекта с 20–30 реквизитами в базу будет записываться 20–30 отдельных строк регистра сведений вместо одной компактной сериализованной записи, что замедляет транзакцию записи объекта.
3. Сложности с типами данных и восстановлением: для универсального хранения значений реквизитов требуется составной тип данных. Восстановление объекта из набора пар «ключ-значение» требует сложного алгоритма сопоставления типов, особенно для ссылок на удаленные элементы или нестандартных типов.

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

Решение 1. Использование подсистемы «Версионирование объектов» из БСП

В большинстве типовых и отраслевых конфигураций (например, в УТ, ERP, КА, БП, УПП) уже присутствует подсистема «Версионирование объектов» из состава Библиотеки стандартных подсистем. Если вы работаете с конфигурацией на базе БСП, внедрять сторонние структуры не требуется.

Рассмотрим, как устроена подсистема в БСП:

1. Хранение данных: версии объектов сохраняются в регистре сведений ВерсииОбъектов. В ресурсе типа ХранилищеЗначения содержится полный XML-снимок объекта, сформированный через СериализаторXDTO или упакованный в сжатый двоичный поток.
2. Гибкая настройка: в режиме «1С:Предприятие» администратор может настроить вариант версионирования для каждого объекта: «Не версионировать», «Версионировать при записи», «Версионировать при проведении» или «По расписанию».
3. Сравнение и откат: подсистема предоставляет пользователю удобный отчет по истории изменений с визуальной подсветкой измененных полей, а также кнопку перехода к любой сохраненной версии объекта.

Важные рекомендации по эксплуатации версионирования БСП:

1. Контроль размера информационной базы: постоянное сохранение полных снимков крупных объектов приводит к быстрому раздуванию таблиц LOB-данных на уровне СУБД. Обязательно настраивайте регламентное задание очистки устаревших версий (например, удалять версии старше 3–6 месяцев или оставлять только последние N версий).
2. Массовые операции: при выполнении пакетной загрузки данных, регулярных интеграционных обменов через API или групповых обработок версионирование необходимо программно отключать на время сеанса, чтобы избежать замедления транзакций и блокировок.

Решение 2. Штатный механизм платформы «История данных»

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

Разберем по шагам, как включить платформенную историю данных:

1. В дереве метаданных конфигуратора откроем свойства нужного справочника (например, Справочник.Контрагенты).
2. В палитре свойств найдем свойство История данных и установим его в значение Использовать.
3. При необходимости можно настроить версионирование для отдельных реквизитов и табличных частей объекта.

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

Выводы и итоги

Проанализировав доступные варианты, выделим оптимальный порядок выбора решения:

1. Если используется современная платформа 8.3 (начиная с 8.3.11) в режиме разработки конфигурации с нуля — наиболее производительно использовать встроенный механизм платформы «История данных».
2. Если конфигурация построена на базе БСП или является типовой — используем готовую подсистему «Версионирование объектов», не забывая настроить регламентную очистку версий.
3. Создание самописного версионирования оправдано только в специфических условиях узких ограничений, при этом рекомендуется сохранять сериализованный снимок объекта целиком в ХранилищеЗначения со сжатием, избегая пореквизитной записи.