Всем привет.
Разбирая чужой код, наткнулся на странную организацию обработки проведения одного документа. Суть в том, что в обработке зачем-то делается запрос к табличной части этого документа с условием
ГДЕ
    |    ИнвентаризацияСостав.Ссылка = &Ссылка";
причем никаких больше отборов не задается, после получения результата все строки тупо перебираются одна за другой.
Какой смысл в таком коде? Почему нельзя было использовать цикл "Для Каждого" по табчасти документа?

а чего это нельзя было?

Вот и я спрашиваю, какие у автора кода могли быть причины написать именно так? Зачем так вообще делается?

Я понимаю, когда леается запрос к ТЧ с каким-то отбором, чтобы не все строки перебирать. Но зачем делать запрос ко всей ТЧ? Что дает такой метод? Прирост производительности относительно одного простого цикла? Сомневаюсь.

забей

(4) Не хочу. Я хочу понять, зачем. Я хочу переписать этот код на один простой цикл. И опасаюсь, что упадет производительность.

(5) Тем более, что проведение документа и так занимает пару минут. (В ТЧ порядка 2-3 тысяч строк).

полный текст запроса приведи

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

Полный текст запроса:
    "ВЫБРАТЬ
    |    ИнвентаризацияСостав.Товар,
    |    ИнвентаризацияСостав.КолФ,
    |    ИнвентаризацияСостав.Цена,
    |    ИнвентаризацияСостав.СумФ
    |ИЗ
    |    Документ.Инвентаризация.Состав КАК ИнвентаризацияСостав
    |ГДЕ
    |    ИнвентаризацияСостав.Ссылка = &Ссылка";


Выбираются ВСЕ колонки ТЧ и ВСЕ ее строки.

(8) Мы теряем время во-первых, на запрос к ТЧ, во вторых, потом на перебор результата.
Я просто не верю, что это может быть быстрее одного перебора по ТЧ.

(10) это для скорости, если групповое проведение документов, ваше "Для Каждого" раз в 15 будет медленнее, чем запрос. А бухгатера ведь очень часто перепроводят документы, поэтому это важно.

(12) То есть все-таки, Запрос + "Пока Рез.Следующий() Цикл" - быстрее, чем "Для Каждого"?

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

(13) мы тут как-то спец.олимпиаду устраивали - Спавочник.Выбрать против запроса. бывает такое, что объектный подход работает быстрее, для этого нужны какие-то особенные флуктуации в атмосфере и железо. но бывает, на миллисекунды, конечно.
судя по тому, как ты описал свою ситуацию, ты занимаешься онанизмом. поэтому (4)

(14) Судя по этому комментарию, не (4), а "делай как тебе удобнее". Собственно, такой ответ меня устраивает.

хорошо. забей на этот вопрос и пиши, как удобней ;)

(14) >Спавочник.Выбрать против запроса
А-ха-ха! Хорошая шутка.

(17) замерь

(0) Проведи опыт.
Сделай замер производительности по двум алгоритмам.
Оч хочется посмотреть на результат :)
(17) Это не шутка. Объектный метод, действительно, иногда работает не медленнее запроса

(15) Это скорее следование общему подходу из типовых: при проведении использовать сохраненное состояние объекта из БД, согласованное со всем остальными данными. Просто в данном конкретном случае другие данные в запросе не используются.

(20) Объект уже записан!

(19) Я к тому, что Справочник.Выбрать() и делает запрос.

(15) не тупи, запрос с таким условием "только к записанным данным"

(23) Мне одному кажется, или в событии "ОбработкаПроведения" - документ уже записан?

(0)Какая конфигурация? ИМХО, это важно.

(24) мне тоже так кажется

(24) Сделай вывод сам по (20) :)

т.е. по (21)

(28) Очевидно, что выводы делать я не могу. Я же туплю, судя по (23) :)

(20) А какие могут быть несогласования в (данных документа) с (данными того же документа из базы) в момент его проведения?

(25) Это не важно просто потому, что вопрос был о двух подходах к одному действию в общем случае.

(21) И что?

(30) читай (0)

(29)Продолжай партизанить. Жди, когда подтянутся телепаты.

+(31) а именно, "Какой смысл?"

(32) Да какие телепаты? Что вам даст название конфигурации? Она написана кем-то с нуля, абсолютно не связана с типовыми.
Прочитайте внимательно сам вопрос (0) и (29), часть 3.

(34) Давай уже замер производительности в студию!)))))

(29) В данном случае несогласования нет. Я говорю про общий подход, который применяется в любом случае. Если завтра понадобится приджойнить еще какой-нибудь регистр для проверки, не нужно будет много переделывать (с цикла на запрос).

(5) "И опасаюсь, что упадет производительность." - религия не позволяет использовать замер производительности?

(35) Замер производительности будет позже. Что-то мне подсказывает, что та оптимизация, которую я уже проделал, дает куда больше результатов :)
Но чисто академический интерес остался, так что замер будет.

(37) Религия позволяет сначала спросить, а потом делать, а не сделать и переделывать.

(34)Применение объектного метода с перебором и запросом в конечном итоге завершается запросом к серверу. Тебе уже несколько раз сказали про замер, но результатов пока нет.

при условии "Она написана кем-то с нуля" - проще спросить разработчика

(39) То есть вы два часа пытаетесь спросить, фаловая это база или серверная? Отвечаю. Файловая.

(40) А если разработчик уже недоступен? Представляете, и такое бывает.

Замеры готовы. Как их выкладывать?

В двух словах. Цикл "Для Каждого Строка ИЗ ТЧ" действительно выполняется выполняется дольше, чем, "Пока Рез.Следующий()" по выборке.
НО! Вся связка "запрос + цикл" занимает примерно столько же времени.
Делать больше число сравнений у меня нет ни времени, ни желания. Я для себя делаю вывод, что цикл по ТЧ просто проще писать, а запрос с обработкой результата более гибок при каких-то сложных проверках и возможном расширении базы.

(39) Вы путаете.

(43) Это кусок типового подхода, забей.

(43) Ну там Остатки по номенклатуре получить, к примеру.
И потом перебрать результат запроса.
Просто у тебя упрощенный случай.

(46) Я понял. Об этом и говорю.

(47) Тебе - тупо перебирать ТЧ документа, не лезть запросом на сервер. Он, да, будет быстр и шустр, ибо попадание в Индекс почти 100%, но все равно.

Но когда нужны остатки - тогда ТИПОВЫЕ и 1С рекомендуют механизм (0).

Но я с ними - не согласен :-)

(0) Как вариант.
Прог писал что-то. Поисковик выдал пример решения (с форума или еще откуда). Прог оттуда скопировал блок и заточил под свою задачу. Так оказалось быстрее.
А теперь давайте всем форумом искать глубинные причины. Работает? Значит нормально.

(50) Как вариант, прог писавший (0) - сдавал 1С:Специалист

(48) Не люблю обращение "Тебе - тупо..." Меня как будто оскорбить пытаются.

В данном конкретном случае весь (неграмотный)код вообще переписать надо. У меня тут во-первых, два запроса и два цикла, во-вторых, идиотское движение со списанием всех 3000 строк и оприходование их обратно, в-третьих, проверка некоторых условий все равно идет, но реализвано в цикле, а не в запросе. Короче, (неграмотный)код и есть. Я уже переписал его и доволен результатом.

(51) прог, писавший (0) - это я или прог, писавший код который я привел?

(52)Не переживай. Ты самый лучший прог.

(53) Я тоже люблю язв без чувства юмора.

а надо было просто
    |    ИнвентаризацияСостав.Товар,
    |    Сумма(ИнвентаризацияСостав.КолФ) КАК Колф,
    |    ИнвентаризацияСостав.Цена,
    |    Сумма(ИнвентаризацияСостав.СумФ) КАК Сумф
    |ИЗ
    |    Документ.Инвентаризация.Состав КАК ИнвентаризацияСостав
    |ГДЕ
    |    ИнвентаризацияСостав.Ссылка = &Ссылка
    | СГРУППИРОВАТЬ ПО
    | ИнвентаризацияСостав.Товар
    | ИнвентаризацияСостав.Цена";

Тогда дублирующаяся номенклатура в строках бы лучше проходила