Когда 1С добавит возможность получать ГУИД в запросах? #386799

Собственно говоря непонятно, делаешь обмен с внешними системами завязанный на ГУИД а потом для сверки данных приходится извращаться так-как в 1С его в запросе никак не получишь.

Че такое ГУИД?

Конструкторы: Из строки Описание: Предназначен для создания и хранения глобального уникального идентификатора GUID.

боюсь даже спросить... а зачем?

А зачем он нужен то?

В запросах, когда мы выводим ссылку на объект мы фактически и получаем гуид, который после система автоматически преобразует

он бывает нужен. Например при организации обмена данными. Или для восстановления некого объекта на который имеются ссылки в базе данных, но который фактически удален.

Я же написал что использую ГУИД в обмене, и для всевозможных сверок, и получения информации из сторонних систем было бы чрезвычайно удобно работать с ГУИДом в запросе, а не заморачивать с перебором полученных объектов в цикле.

никак... им лень.

сори, я прочитал только заголовок :))) а то что там еще сообщение даже не обратил внимание.

Просто странно получается что в системе нет нормального доступа к ключевому полю таблиц.

В чем заморочка? Написать лишних 7 строчек кода?

ну помог бы человеку))))

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

Удобнее или быстрее?

и то и другое

Удобнее - да. Быстрее - отнюдь. Да, поиск в цикле. Да, поиск 2 раза. Однако поиск по индексу. Однако, результат поиска кэшируется сервером SQL. Но, если не терпится - ADO в руки-ноги.

основы СУБД подучить надо. что быстрее - миллион записей тащить на сервер и потом по каждой записи запрос делать или этот миллион сразу на сервере обработать и получить на выходе всего лишь 2 записи?

1. Можно GUID добавить в каждый объект и перед записью нового заполнять. 2. Можно запрос делать по временной таблице, которая получилась из запроса и потом была дополнена гуидами.

Заведи реквизит строковый и перед записью пиши туда идентификатор, всего делов то. А ждать что 1с это сделает можно ооочень долга

На какой сервер, что ты собрался тащить? Какие записи? Не путай. Уот, еще 2 товарисча. Что быстрее, скажите мне. Поиск по 16 байтному индексированному значению, или по 72-х байтному индексированному? А еще расскажите мне, товарисчи, как в SQL храняться строки? Ууу? Чем временная ТЗ будет отличаться принципиально от ?

Если критично быстродействие - делай через ADO. Не забывай только про инверсию GUID в 1С и в SQL.

ну конечно проходить результат запроса и обрабатывать каждую строку в табличке значений порождая короткий запрос на каждую строку например 10**6 раз намного лучше

Все будет тащиться на сервер, все правильно, не путай народ.

По поводу отличий могу сказать, что в общем-то ничем, лучше всего первый вариант конечно же. Это как и с типом документа, когда в журнале нет возможности сделать отбор по нескольким типам документов, а хочется, и приходится делать в каждом документе реквизит "Тип документа" :))

Еще можно прямой запрос к SQL делать кстати :))

Давай спросим автора, что ему нужно? 1. Автор, у тебя в 1С есть список GUID-ов, допустим строковых и набор условий. И ты хочешь одним запросом получить записи (допустим справочника) согласно этому списку GUID-ов и набору условий? 2. Автор, ты подключаешься к 1С из сторонней проги, через COm и хочешь выполнить запрос и получить список GUID-ов?

Вообще автор написал, что 1 его точно интересует. Может и 2, но 1 точно.

* интересно, задумывались ли местные мистяне, почему запрос в цикле - зло?

* просто прямо таки априорное зло

, в файл-сервере = зло в квадрате

Читаем всю табличку на клиента. Это понятно. А в клиент-сервеном почему?

Ладно, немного направлю свои мысли в нужное русло, а то что - то мистянский разум не думает. Чем циклическое зло ВЫБРАТЬ    ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.Номенклатура,    ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.Склад,    ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.КоличествоОстаток КАК КоличествоБух,    ПартииТоваровНаСкладахОстатки.КоличествоОстаток КАК КоличествоУпр отличается от циклического зла: ВЫБРАТЬ    Номенклатура.Код,    Номенклатура.Наименование ИЗ    Справочник.Номенклатура КАК Номенклатура    Номенклатура.Ссылка = &Ссылка Ааа?

по моим ИХМО наблюдениям, еще и объект "Запрос" очень долго создается... переводил одну контору с клиента на файл, некоторые куски кода (да те же внешние печаные формы) раз в 30 медленнее стали работать...

+ прада там был ужоссс... запрос был именно в цикле

Скучно с вами, товарисчи знатоки 1С-а.

Даже не поспоришь с пеной у рта

Гон. Вот еще пример: один товарищ, главный 1Сник на своей фирме, утверждает, что объект Запрос много памяти ест, поэтому во всех модулях объявляет одну переменную модуля типа Запрос и её использует. (речь именно об объекте Запрос, а не о результате запроса - но им еще тоже надо умудриться память сожрать)

А что задумываться-то? :)) Лучше один раз сходить в магазин за двумя кило сахара, если магазин в соседнем районе, чем два раза по кило :)) Да плюс тебя каждый раз будут тормозить менты по пять раз (RLS) :))

Да, вот про RLS не подумал. Ладно, объясню свою мысль. Пусть не будет RLS. Вариант 1 будет злом, ибо мы циклически получаем остатки и циклически делаем соединения. Кроме того, есть еще косвенное зло - это служебная информация, отправляемая на сервер приложений, на сервер SQL и обратно. Вариант 2 не будет злом, ибо SQL все равно циклически ищет записи по списку ссылок. Дольше будет тольк из за большего объема служебной информации.

Ты не прав

Гон (в ответку) ты тест производительности произведи, а уж потом умничай

Где? Самому интересно

Тем, что у тебя выполняется один запрос или несколько, что непонятного? :)) Ты пробовал в SQL напрямую запросы выполнять, без 1С?

Пробовал

И?

Выполнялись. Вопрос можно? Вот у меня такое впечатление, что вам сказали, что запрос в цикле - зло, даже пример показали (и пример действительно показал, что запрос в цикле - гораздо медленнее, чем один запрос) и вы приняли это за аксиому. Я не берусь утверждать, что запрос в цикле одинаково быстр, как и запрос по списку. Я прошу вас попытаться подумать и объяснить мне, ПОЧЕМУ запрос в цикле медленней, чем по списку.

объясняют в ВУЗах. еще можно самообразованием занятся.

Нам не объясняли. Может расскажешь?

ты ленив и я ленив. вместе мы ленивы. яндекс, sql.ru - самообразуйся

Кто ленив ?

я за деньги работаю. а за бесплатно либо ленюсь, либо самообразуюсь, либо делаю интересную/перспективную работу. еще вопросы?

фу. нафлудил сколько. заканчиваю...

Вопросов к тебе не имел, ты сам пришел.

И все - таки?

Да блин, я уже сказал уже. Если коротко, то запрос на SQL-сервере по получению порции данных на 1000 записей делается быстрее, чем два запроса по 500. Быстрее так потому, что требуется не только выполнить запрос, но и выполнить все остальные операции, связанные с этим, то есть соединение с SQL, RLS и прочяя шляпа.

Тоесть, скорость поиска в SQL будет одинакова?

Да блин, какая скорость поиска, ты о чем вообще? Я же написал все вроде, ДВА запроса по 500 записей будут медленнее, чем ОДИН на 1000.

да ты не вкурил... туз в рукаве прячет...

Время на компиляцию текста запроса велико? Или что?

Чего-то ты не договариваешь.

Читай по губам :o) MS SQL Server ДВА запроса подряд отработает медленнее, чем ОДИН, но с выборкой в два раза больше. Почему так работает MS SQL Server можно почитать где-нить, но в любом случае с 1С это никак не связано. А с 1С связано то, что кроме разницы в самом скуле, еще сама 1С будет ДВА раза щемиться к скулю, будет ДВА раза пихать в запрос RLS, будет ДВА раза делать всю кучу действий, связанную с выполнением запроса вместо ОДНОГО. Какую именно кучу действий ты можешь посмотреть в профайлере, если интересно.

Почитай рекомендации 1С, о том что количество обращений к базе необходимо минимизировать. На курсах в один запрос даже наименование товара тянули, на тот случай если надо будет сообщить о превышении остатка. Если ты конечно доверяешь разработчикам 1С, если нет - напиши свои рекомендации.

Вы вне темы. Вообще мимо.

надо б  в понедельник апнуть... щас как-то не то...

Ну вот профайлер: Запросец по нашей тематике: Сухой остаток: 577 миллисекунд перебора в цикле против 63 милисекунд единого запрос, из которых 47 миллисекунд на формирование Временной таблицы из массива ссылок, 16 миллисекунд на выборку. Однако. Там же ещ логировалось все профайлером. Для цикла - профайлер сделал дикое число записей (хотя бы просто текста). Поэтому не показатель, ибо теже 16 миллисекунд - это почти квант времени винды. Тем не менее, готов признать, что цикл гораздо медленнее единого запроса. Объяснений от вас я не дождусь, буду читать сам. И на последок, я доволен этой веткой. Сегодня я узнал еще одно заблуждение. Конструкция Код=СсылкаСправочника.Код; читает объект полностью, несмотря на заверение книги "Профессиональная разработка в 1С" про особенности чтения основных реквизитов объектов.

Сделаю проще - буду получать не ссылку, а все поля таблицы..