Перенос данных из конфигураций, использующих механизм Разделения данных (Data Separation), в обычную базу — это задача повышенной сложности. Основная проблема заключается в том, что данные в источнике изолированы на уровне СУБД. Когда мы пытаемся выгрузить их стандартными средствами Конвертации данных 2.0 (КД 2.0), мы сталкиваемся либо с невидимостью данных из других областей, либо с "фаршем" — наложением кодов справочников и номеров документов из разных областей друг на друга.
В этой статье мы подробно разберем, как правильно организовать процесс слияния разделенных данных, избежать коллизий и сохранить целостность ссылок. Мы рассмотрим программные методы выгрузки, стратегии поиска объектов и способы трансформации данных "на лету".
Механизм разделения данных в 1С (часто используемый в сервисе 1cfresh или для реализации мультиарендности в самописных базах) добавляет в таблицы базы данных неявные поля-разделители. Если в базе настроено Независимое разделение, то объекты в разных областях могут иметь одинаковые коды, номера и даже одинаковые уникальные идентификаторы (UUID/GUID), если они создавались программно.
Проанализируем основные препятствия:
Чтобы выгрузить данные из всех областей сразу, нам необходимо обойти ограничение сеанса. Рассмотрим наиболее эффективный метод — использование Правила выгрузки данных (ПВД) с типом выборки "Произвольный алгоритм".
Для начала нам нужно запустить выгрузку под пользователем, имеющим права на администрирование данных (полные права). В обработчике ПВД Перед выгрузкой данных мы можем использовать возможности платформы по работе с разделителями. Разберем пример кода для перебора областей:
// Пример алгоритма в ПВД для выгрузки справочника Контрагенты из всех областей
ЗапросОбласти = Новый Запрос;
ЗапросОбласти.Текст = "ВЫБРАТЬ Значение ИЗ РегистрСведений.ОбластиДанных"; // Укажите ваш источник разделителей
ВыборкаОбластей = ЗапросОбласти.Выполнить().Выбрать();
Пока ВыборкаОбластей.Следующий() Цикл
// Устанавливаем расширение состава разделителей для текущей итерации
МассивРазделителей = Новый Массив;
МассивРазделителей.Добавить(Новый Структура("Имя, Значение", "ОбластьДанныхОсновныеДанные", ВыборкаОбластей.Значение));
УстановитьРасширениеСоставаРазделителей(МассивРазделителей);
// Теперь запрос внутри ВыгрузитьПоПравилу увидит данные конкретной области
ВыборкаОбъектов = Справочники.Контрагенты.Выбрать();
Пока ВыборкаОбъектов.Следующий() Цикл
ВыгрузитьПоПравилу(ВыборкаОбъектов.Ссылка, , , , "Контрагенты");
КонецЦикла;
КонецЦикла;
Этот метод позволяет последовательно извлечь данные из каждой области в один XML-файл. Однако помните, что при использовании УстановитьРасширениеСоставаРазделителей нужно быть внимательным к правам доступа и версии платформы (рекомендуется 8.3.10 и выше).
Чтобы "Молоко" и "BMW" не слились в один объект из-за одинаковых кодов, мы должны изменить данные в процессе выгрузки или загрузки. Рассмотрим вариант с добавлением префикса области.
В Правиле конвертации объектов (ПКО) в обработчике При выгрузке или Поля поиска мы можем динамически модифицировать код. Выясним, как это реализовать:
ТекущийРазделитель, который будем обновлять в цикле ПВД.Код или Номер пропишем алгоритм добавления префикса.
// В обработчике ПКО "При выгрузке" для свойства Код
Значение = Строка(Параметры.ТекущийРазделитель) + "-" + Источник.Код;
Таким образом, в базе-приемнике мы получим объекты с кодами "1-001" и "2-001", что гарантирует их уникальность и исключает потерю данных.
Если мы объединяем данные, нам нужно решить, по каким полям искать объекты в приемнике. Рассмотрим ситуацию, когда поиск по ГУИД невозможен из-за их дублирования в источнике. В этом случае мы должны создать синтетический ключ поиска.
Проанализируем шаги настройки поиска:
Разделитель + Код).Поля поиска пропишите логику сопоставления. Если объект не найден по ГУИД (или мы его намеренно игнорируем), выполняем поиск по коду с учетом области.Важно помнить про Общие данные. Справочники вроде Валюты или Банки обычно не разделены. Для них префиксы добавлять нельзя, иначе вы получите столько дублей валюты "Рубль", сколько областей было в источнике. Для таких объектов настраиваем поиск строго по ГУИД или по уникальным реквизитам (ИНН, Код Альфа и т.д.).
Если перенос выполняется не разово, а итерационно, крайне важно использовать регистр Соответствия объектов информационных баз. Рассмотрим, почему это необходимо:
Когда мы переносим объект из "Области 5", в регистре соответствий должна появиться запись, связывающая ID этой области, исходную ссылку и ссылку в приемнике. В КД 2.0 для этого нужно включить опцию "Использовать для идентификации объектов приемника регистр соответствий" в настройках конвертации.
Это позволит платформе однозначно понимать, что объект "Контрагент А" в приемнике соответствует именно "Контрагенту А" из "Области 5", а не одноименному объекту из "Области 10".
Не пытайтесь просто "отключить" разделение в базе-источнике перед выгрузкой. Посмотрим, к чему это приведет: платформа начнет реструктуризацию таблиц. Если в разных областях есть записи с одинаковыми уникальными индексами (например, одинаковый код справочника), база "рассыплется" с ошибкой СУБД Duplicate key value.
Вывод: Трансформация данных через Конвертацию данных 2.0 — самый безопасный путь, так как вы контролируете процесс слияния на уровне бизнес-логики, а не на уровне физических таблиц.
УстановитьРасширениеСоставаРазделителей для смены контекста области в цикле.Следуя этим рекомендациям, мы сможем эффективно объединить данные из любой разделенной конфигурации в одну общую базу, сохранив всю историю и избежав дублирования или потери информации.