Быстрый перенос данных с ГУИДами #809460

Всем доброго времени суток. Есть задача по переносу данных из 1с в sql. Причем в качестве объектов передавать не их человеко читабельные представления в виде кода или наименования а ГУИД объекта. Если последовательно перебирать выборку и на каждом объекте применять метод XML строка, то получается безумно долго. Докопался до метода с сериализацией таблицы значений вот таким способом Работает в разы быстрее, но опытным путем установлено, что там нормально работает только на таблицах, в которых содержится 1000 строк или меньше. Потому приходится обходить выборку и формировать маленькие таблички по 1000 строк. Этот метод все равно быстрее, чем первый примерно в 8 раз. В минуту грузим 10000 записей. Замер производительность показывает, что 60 времени уходить на операцию заполнения значений строки таблицы значений Хотелось бы еще ускорить процесс но уже не знаю куда копнуть. Подскажите какие еще могут быть варианты быстрого получения ГУИДов или какой-нибудь хитрый способ разбиения результатов запроса на несколько маленьких табличек. Вариант выгрузить в таблицу значений все, потом пронумеровать и делать выборку из нее по частям исходя из номера пробовал. Выходит дольше. Хочу скорости )) Предложите плиз какие-нибудь варианты

а чего, взять гуид объекта сразу с таблички в скуле и переписать куда надо, не вариант ?

Я бы взял, да найти не могу...

т.е берешь _IDRRef из таблички _Document*** и инсертишь куды те там надо

Он же ведь там в другом виде хранится

файловая что ле ?

в том же самом и хранится, в виде гуида

Нее... Скуль

просто в 1с "чутка" преобразован

мне нужно ваот так - 00072dd6-f326-11e4-8936-e4115be3c6a9 а в скуле вот так - 0x0000FE44C60311E3964FE4115BE3C6A9

Так что, 1с тут вообще не нужен, ну разве что запрос по ado там запустить

и че ? :)

тебе в строку гуид нужно преобразовать?

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

преобразовать гуид в уид можно же, в скуле тупо хранимкой

?

Хранимка штука конечно интересная, но боюсь моем случае не подойтет. Мне нужно с разных конфигураций данные собирать, причем где-то в чистом виде, где-то результаты запросов для отчетов... И под каждую базу еще и преобразования делать... Тяжеловато будет

Ну, тогда выбирай - тебе либо шашечки, либо ехать.

Если "ехать" - то при добавлении любого объекта мне потрудиться не кисло надо будет... Если "шашечки" - то я отдал инструмент и забыл... Мы ж ленивые люди... Но хочется что бы побыстрее было ))

Что именно вкладывается в понятие "потрудится" ? Ты же имена таблиц и  полей, не руками будешь добавлять в запрос.

Что-то плохо у меня картинка складывается... Мне получается надо будет запрос 1ски конвертнуть в скулевый. Его там исполнить. Обойти результаты скулевого, преобразовать уид и записать в другую базу...

нет, нужно просто выполнить sql запрос который сделает insert into select

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

если через скд делать, то можно напрямую ссылки в гуиды переводить

СКД не прокатит... Рассматривал этот вариант. Нужен универсальный механизм, что бы им дергать из любой базы 1с. А им я получу com объект

Смотри, перечисляю все доступные методы решения этой задачи: Вариант2 - используя функцию Новый БуферДвоичныхДанных и сложение по модулю И Вариант3 = VBScript.RegExp Вариант4 = самодельный парсер строк. Выбирай любой)))

Вариант4 - это наверное то, что я уже изобразил... 1 и 3 вряд ли будут универсальны. а вот 2 кажется интересным. завтра посмотрю в его сторону

Вариант 4 ужасный колхоз. Пример с вариантом (3 и 2) смотри ниже (он универсален), так как guid формируется по RFC4122 Как оказалось, платформа не может в сдвиг. Пришлось немного подшаманить. В итоге получилось вот так (тут сразу с замером производительности. Сей код (10000 итераций) на толстяке выполняется 1400 мс. Что касается твоего замечания насчет "Работает в разы быстрее, но опытным путем установлено, что там нормально работает только на таблицах, в которых содержится 1000 строк или меньше" то тут все просто - сериализатор использует DOM-анализатор, а это значит, что весь XML загружается в оперативную память, а, учитывая то, что у тебя код написан с утечками памяти (хотя бы то, что ты не закрываешь xml-дескрипторы), получаешь обозначенные ограничения. В любом случае, в твоем конкретном примере использование XPath будет куда более эффективнее.

Не очень понял как этот код применим для меня. Объясните на пальцах плиз. Есть выборка из базы 1с, к которой я подключен com соединениям. Выборка следующая Выборка.Ссылка - com объект (здесь должен быть ГУИД) Выборка.Наименование - строка Выборка.Код - Число Данные по этой выборке я должен вставить в sql базу.

Ты о чем спрашиваешь в посте?

Изначальная задача. Есть N баз 1с, нужно создать универсальный инструмент по выгрузке данных из них в базу SQL. Далее я описывал свое решение в поисках его оптимизации

скд можно и в чужой базе выполнить

схему собирать ручками

Большой плюс будет, что не нужно будет ссылки возвращать, а сразу строки

Вот это ты к чему написал? «мне нужно ваот так - 00072dd6-f326-11e4-8936-e4115be3c6a9 а в скуле вот так - 0x0000FE44C60311E3964FE4115BE3C6A Напиши, пример guida и его xml-представления 1С любого справочника.

Тут вопрос: как из языка 1с перевести в язык скл? свой парсер писать. Слишком сложная задача

Это была часть обсуждения. Задачу я уже озвучил. Схему раками пособирать - неплохая идея... Попробую

раками не надо, итак все через них.. :)

Вы пример не прислали, какой - я написал.

Зачем вы храните во внешней базе ссылку как nchar? Если это тип binary?

как ты данные из 1с тащишь ?

Это не сложно, но, думаю, ОПу это не поможет.

не понимаю, в чем у тебя сложность сразу вытащить sql запросом данные из 1с и инсёртить их в твою табличку. Так же, динамически собираешь текст запроса и привет

У меня помимо баз 1с есть еще и wms система, откуда тоже данные тащить надо, а ключами по той же номенклатуре являются строковые ГУИДы... Потому вот такая и заморочка

Под ГУИДом я понимаю уникальный идентификатор вот такого вида 00072dd6-f326-11e4-8936-e4115be3c6a9

Тогда понятно. Колхоз, в общем.

Я бы рассказал про представления (VIEW) и синонимы (SYNONIM). Но порекомендую почитать книжки по MS SQL или не трогать сервер.

Почитать - это безусловно беспроигрышное предложение

сделать общий реквизит "ГУИД" и один раз его заполнить по всем базам? плюс подписка на новые ссылочные элементы ПриЗаписи

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

Разумеется, еще и разобраться. Задумайся: почему в 1С ссылки хранятся как binary в 1С, а в вашей там какой-то WMS (?) системе как строки. Они, поди, хоть в индексе? Если бы ты знал, что такое view, то знал бы, что в sql можно сделать хоть сколько угодно view, а в 1С это подключить как внешний источник. А еще тот код, что я тебе написал выше, прекрасно работает в sql и поместится в одну строчку как скалярный оператор - надо его только правильно переписать.

Ты не поверишь, но вьюхи использую в полный рост. И как внешние источники и в отчетах. Причем вьюхи на скулевые и орокловые. Так что сильно не выделвайся. И почему ключи не строковые тоже все студенты знают. Строковый ГУИД используется при интеграции и от него мне не убежать. Вот и думаю как все сделать оптимально

предлагаешь выкинуть эту wms и написать свою?

Подтупливаю что-то в пятницу вечером. Вот это выражение Тип("НаборДанныхЗапросСхемыКомпоновкиДанных") через com как получить?

Схему легко... СхемаКомпановки = мБаза.NewObject("СхемаКомпоновкиДанных"); А тип что-то туплю...

а чем УникальныйИдентификатор плох? 13500 вызовов за 0,14 сек: