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