Доброго времени суток. Собственно вопрос в скорости.
Есть 2 типовые базы ЗУП 3.1.  Нужно сделать третью пустую базу и залить туда данные из первой ЗУП и из второй ЗУП. что бы вести 2-а ООО в одной базе. Но эти нужно так же оставить.
Собственно вопрос в скорости. и продуктивности.

Сначала я потестил ВыгрузкуЗагрузкуXML типовую.. После 4-х часов выгрузки. Закрыл процесс руками... не дождался.. Учитывая что база совсем не большая.
Далее я попробовал КД. создал правила. Через Универсальную загрузку выгрузку, выбрал там правила, период поставил ради теста 1 месяц. Идет уже 2 часа, только выгрузка. Сколько осталось хз.

Собственно не к спеху. Просто интересно, кто делал? есть какой-то оптимальный по скорости способ?

напрямую в sql думаю самый быстрый

(0) Выгрузка/загрузка XML
200 человек, 5 лет -- примерно 1 час на выгрузку. Загрузка 2 часа (примерно)

Настройки
Документы с движениями
Справочники


Выгрузка конечно в серверную папку

а) Выгрузить документы с движениями по месяцам кварталам с зависимыми спр, вр, хар
б) Выгрузить независимые регистры сведений (кроме АдресныеОбъекты) с зависимыми спр, вр, хар
--- вот тут внимательно, есть куча системных независимых регистров, которые дублировать "нехорошо"

---
После загрузки выгрузки внимательно убиваем дубли
1) ПВР.начисления, ПРВ.Удержания
2) Справчоники:
   Физические лица
   Валюты
   Должности
   Графики
   Производственный календарь
   СтатьиРасходовЗарплата
3) Осторожно с системными справочниками и регистрами сведений

https://v8.1c.ru/obuchenie-programmistov/primery-razrabotki/sistemnye_protsedury_i_funktsii/kak_prosmotret_strukturu_tablits_informatsionnoy_bazy.htm

кстати на ИС еще нет готового?
ну там обработка чтобы пару баз свести или наоборот разделить напрямую в sql ?

(0) Выгрузить документы с движениями по месяцам кварталам с зависимыми спр, вр, хар

Акцентирую внимание на "с зависимыми". Иначе будет беда с предопределенными значениями в справочниках

(4) там подменять надо

одна база берется как главная и к ней надо служебные привязать из второй, откуда переносят
быстрее всего это сделать (1)

ибо никакой xml никогда не будет быстрее чем просто запросы sql пусть и между базами

(5) Я не уверен, что средствами и запросами SQL я смогу в третью базу, слить первую и вторую ))

"Напрямую в SQL" - "Это же не наш метод"(с). Если бы автор владел этой методикой - этой ветки не было бы. Забыли про SQL.

PS: я, как фанат РИБ, сливал две базы созданием РИБ из трех узлов (навеяли слова ТС - "Но эти нужно так же оставить").

(6) первую слить в третью простейше
вот вторую добавить это да ибо все задублится

(8) и нафига?

(10) Скажем так: ради комфортной миграции пользователей :)

(0) а что с нумерацией делать, или там префикс разный и нет проблем с этим?

(12) Префиксы организациям присвоить и перенумеровать документы перед слиянием - это такое простое действие, сто даже не стоит упоминать :)

(13) ну я так на всякий случай напомнить)

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

"Но эти нужно так же оставить" - вот это самая сложная задача. сразу видно, что за компом второй день.
сливаешь ту которая меньше в ту, которая больше, разве это не очевидно? 4 часа для 1с это еще мало. объемы баз ты не озвучил. мощность оборудования тоже. даже не сказал, скульная она у тебя или файловая, а может вообще сетевая. что же тогда от нас хочешь? выгрузка/загрузка xml вполне для этого подойдет.

(15) Да, шанс незначительный. За пару десятков лет ни разу не было :)

(17)

>>>Да, шанс незначительный. За пару десятков лет ни разу не было

Попросили слить 3 бухг.базы (БП)

- У вас базы точно разные ?
- Ну конечно!
Проверяю guid-ы организаций. Организации разные, гуиды одинаковые. Местный админ размножал базы копипастом.

От задачи я отказался

(12) Прификсы славо богу разные в базах.

базы sql все.
Прификсы разные
ЗАмерил скорость. если выгружать 1 месяц. то выгружается 33 минуты) сколько загружается пока хз

(18) фигня какая подменить уиды

(18) Раз такая пьянка, то нужна обработка проверки уникальности гуидов :(

(22) а как быть, если в двух базах номенклатура пересекается?) В этом случае будут дубли, если тупо по гуиду проверять.

(23) то же самое касается и других справочников (парнтеры, контрагенты, валюты и т.д.)

(24) (23) Поэтому имхо, лучше через КД правило написать.

(21) Это ссылка на организацию - это не фигня - это,считай, всю базу переворошить с документами и регистрами.

(0) Не рекомендую объединять, если в этом нет острой необходимости. Если никак не отказаться от работы, то писать правила в КД2.
(26) Прямыми запросами SQL минуты 2.

(24) Поиск и замена дублей - не рутинная операция, а творческая :)) Особенно когда слияние баз проявляет противоречивые, взаимоисключаемые  данные в ранее автономных базах.

(28) я предпочитаю, сразу правильно переносить, чем потом искать дубли, удалять, перепроводить документы. Потом еще рестуктуризацию делать, так как база сама не срежет удаленные объекты с объема базы.

(27) >Прямыми запросами SQL минуты 2

угу
главное сначала выяснить что этот гуид только к одному объекту относится, теоретически может быть один гуид у разных объектов
ну или замену не подряд во всех таблицах а только в нужных и в нужных полях

(30) >ну или замену не подряд во всех таблицах а только в нужных и в нужных полях
Мы по такому пути делаем замену, чтобы не лопатить все таблицы

(27) я в КД2 и написал. ну как написал на кидал для теста. сейчас буду править по итогу загрузки

(18) Бух база не самая тривиальная, а Вот ЗУП, любит писать регистры где не поподя, обожает иметь ссылки на документы, а не не пустышки :)

(29) "я предпочитаю, сразу правильно переносить" - разумеется, если в дублях реквизиты одинаковые, то можно слияние доверить обработке. А что есть "правильно"и кто это решает если в дублях различаются значения реквизитов? Имхо, решение должен принимать компетентный в этих вопросах сотрудник, а не тупой алгоритм слияния уровня "Кто первым встал - того и тапки" :(

(34) разумеется речь шла о очевидных объектах (ИНН/КПП совпадает, Артикул/Наименование/ШК и т.д.) Обычно все эти моменты слияния обговариваются с компетентным сотрудником, знающим учет в этих базах и после анализа БД принимается решение, по каким полям считать объекты уникальными.

(35) и разумеется сложность и стоимость подобного слияния довольно высоки
не один день может уйти чтобы все вычистить

(36) именно так. Когда говорят, да все это легко и просто, всего то 2 одинаковые базы объединить, даже правил сложных писать то не надо, можно вообще тупо ВыгрузкаЗагруза и все дела. Потом делают тяп-ляп и в базе куча дублей, начиная от валюты, единиц измерений и заканчивая полной каши в номенклатуре/контрагентах. Потом еще умудряются с этим делом поработать и ищут нового спеца, чтобы им эти дубли привел в порядок и зачастую за это стоит еще дороже)

(36) "не один день может уйти чтобы все вычистить" - именно поэтому я и использовал РИБ. Предварительный анализ данных позволили использовать такой метод. Пользователи продолжали работать в обычном режиме в подчиненных узлах, а я и компетентные сотрудники в это же время устраняли дубли в корневом узле. Все изменения оперативно переносились между всеми тремя базами. Чтобы избежать возникновения хауса, на время существования дублей, пользователем были даны указания по выбору записей, ориентируясь по префиксу организации. Это несколько упорядочило принцип работы с дублированными данными. В течении двух/трех дней обработками были массово устранены дубли в подчинённых, а в течении месяца "в ручную" - и основных справочниках до практически приемлемого уровня. Все остальные вопросы были решены в течении квартала. Без стресса и аврала.

PS: я не рекламирую и не рекомендую указанным мной метод. Просто поделился опытом. Просто навеяло словами собеседника.

(38) Можно было тоже самое и без РИБа провернуть
Обработками предварительно для дублей в двух базах сделать одинаковые уид, пока там юзеры работают
Затем слить в одну, проверить что основное пашет и юзеров из двух запустить в одну общую
И продолжить удалять дубли уже в одной