Что быстрее? НайтиПоРеквизиту или Запрос? #653596

Сабж. Надо подгрузить из экселя один реквизит в мульон договоров БП20.

Запрос

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

Только не запрос в цикле :)

А НайтиПоРеквизиту - это как раз оно. Так что при всем богатстве выбора запросу альтернативы нет.

а что быстрее: установить отбор использовать или установить параметр в динамическом списке? :)

&НаСервере щаз буду тестировать на 10 записях. а потом на ночь оставлю...

а такое запросом без перебора можно сделать?:)

из цикла вытащи и .ссыка убери tt

точнее второе вытащить, а первое просто точку убрать

.ссыка у меня это привычка :))

Стесняюсь спрсить. А НайтиПоРеквизиту это не запрос?

запрос в 8.1 выполняется за 8 секунд, тот же самый запрос на 8.3 - выполняется минуту :) 8.3 вывод: самая ужасная платформа :)

Сначала все "Договор"(где строковое имя) в таблицу вытащить, а потом 1 запрос

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

Байки.

нет не байки, возьми один документ и выбери у него два реквизита и ссылку, тут же объедини с другим видом документа, выбери те же два реквизита и свою ссылку, потом сгруппируй получившийся результат по двум реквизитам и выведи итог в дерево. Запрос1 Объединить ИТОГИ через СКД те же 8 секунд, через консоль - минута, может чуть более.

выведи иерархию всю с итогами.

НайтиПоРеквизиту быстрее, если ищешь не в цикле. Если надо искать в цикле, лучше пиши запрос, который обработает весь свод информации без цикла.

Кокос похоже romix, но почему-то Кокос :)

это я из книги знаний мисты взял код :)

Делать мне больше нечего, повторяя ваши глупые тесты.

Как ни удивительно, но сегодня прав, именно в ситуации .

<<НайтиПоРеквизиту быстрее, если ищешь не в цикле. А почему быстрее?

:)

мне не просто искать нужно. мне еще нужно "если нет то создать" :)

Ставим вопрос по другому: план запроса для НайтиПоРеквизиту и Запрос какой? Операция SEEK быстрее SCAN. А вообще можно мини-конфигурашку сделать, рандомом генерировать 20000-50000 элементов справочника и проверить.

Потому, что НайтиПоРеквизиту это встроенный запрос платформы

= > 500 000 строк :)

Ого. А чем встроенный запрос лучше не встроенного? Почему он быстрее будет искать?

А убрать запрос из цикла нельзя??? Выборка.Сбросить с Выборка.НайтиСледующий пошустрее существенно.

Значение уникально?

а с параметрами как быть?:)

уникален ВнешнийКод и ИмяДоговора. Вообще это номер счета. а у них договор = счет.

Сам подумай, все тебе разжевывать надо :)

я просто через КД грузил и он у меня при загрузке всех договоров валился. я поставил договора по ссылке. все загрузил. теперь подгружаю левым способом через текстовик сами договора. молюсь чтобы это все влезло в файловую БП30

Спасибо, я буду гордиться, что сам H A D G E H O G s меня похвалил :0)

Вот Вам почва для размышлений 1. Поиск по реквизиту 2. Запрос по реквизиту 3. Запрос по массиву значений и поиск по единственному 4. Тоже что и 3, но выгрузка в ТЗ, добавление индекса колонке и поиск

Вот так: &НаСервере

спасибо за урок. Буду теперь всегда так делать. :)

в базе, естественно, никто не работает?

Это столько буков надо написать, чтобы найти по реквизиту? :)

Файловый вариант, никто не работает

А нормальные пацаны про файловый вариант и не знают...

и это Перечисления.ВидыДоговоровКонтрагентов.СПокупателем являются скрытыми запросами в цикле (см. замер производительности) - их надо за пределами цикла 1 раз получить и подставлять

+ ты так не смеши больше с файловым вариантом и производительностью. Ладно?

Расскажи про разницу в относительных измерениях, а я следом выложу скрин клиент-сервер с 20 пользователями онлайн

Подсказка - существенные отличия только в одной цифре - в какой?

Подумал. Не придумал. Разжуй пожалуйста.

в дополнение к клиент-сервер (32 бита, СУБД MS SQL 2008), 20 пользователей онлайн

тогда не надо утверждать - "Байки" :)

И ещё, в отличии от не найдет созданные в цикле элементы, поэтому при создании нового договора и контрагента их нужно добавлять в кэш (массив, соответствие) и искать их там дальше по ключу ВнешниКод для контрагент и ВнешнийКод + СимволКоторыйНеМожетПрисутствоватьВДоговорИНаименование+Наименование для договоров. Это позволит избежать задвоения.

ну в данном случае я думаю этого не произойдет. в исходной таблице по определению нет задвоений. А так всё прошло ок. Часа за два загрузилось.

а новые контрагенты не создаются ибо всё подгрузилось через КД. надо было только договора подгрузить.