Обход выборки несколько раз #703521

По результатам запроса получилась выборка, которую в цикле Пока Выборка.Следующий Цикл обошли. Теперь нужно ее еще раз обойти. Как встать на начало? Ибо, если еще раз пишу Пока Выборка.Следующий Цикл, то он делает вид, "что уже все сделал, пятница и пошли все на фик"

Выборка.Сбросить;

вначаловыборкиемоедлякогоспписали?

Выборка.Сбросить

Выгружай в таблицу значений и гуляй по ней как по бульвару)

Сразу видно семерошника :))

спасибо

За такое линейкой по рукам бьют.

Я бы бил разработчиков типовых за их Выборки.. ууу.. шайтаны.

Что такое повторный обход выборки? Это по сути переоткрытие курсора на sql-сервере и повторная передача всего объема данных. Уж лучше 1 раз загрузить в ТЗ и дальше с ней работать.

Выборка нужна только если требуется 1 раз данные получить и забыть про них..

Откуда дровишки?

Есть другая инфа, т.е. вы считаете, что выборка полностью кэшируется 1с? Чем тогда выгрузка в ТЗ хуже?

Ну а так конечно прикольно сразу ТЗ на сервер предприятия передавать, вдруг памяти хватит и она не засвопится. Делов то... Выборка получается порционно с скуля.

с каких пор выборка стала курсором на SQL?

Особенно радуют ТЗ с иерархическими выборками....

А может даже она на клиент передается, не проверял. Но выгрузка в ТЗ ничем не хуже.

Ну разумеется, надо без фанатизма.. С другой стороны, если в результате запроса получается нечто огромное - скорее всего, запрос составлен неправильно или неправильно поставлена задача.. А с нормальными выборками никаких проблем с выгрузкой в ТЗ нет.

Не надо таких выборок. Мы сами может плоскую ТЗ отсортировать по ключам иерархии и обойти иерархически. На Клиенте. Весь мир бьется за распределенные вычисления, децентарилизацию, а товарищи советуют на Сервер все тащить.

Это дерево называется )))

как раз наоборот тенденция - обработка в кластере серверов

А что, разве нет? Выборка - это способ обращения к курсору, полученному при выполнении запроса. Фактически это морально устаревший навигационный подход к обработке результатов запроса. Выгрузка в ТЗ и то более соответствует реляционной модели.

Ты это у разработчиков 1С спросил?

покажи пруф

У вас есть другое объяснение?

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

Попробовал сейчас sql-профайлером отследить, что происходит при получении выборки. Это не курсор. Курсор - это изнанка объекта РезультатЗапроса. А выборка - это еще хуже. При создании выборки создается временная таблица с результатами запроса. А каждое выполнение метода Выборка.Следующая вызывает "запросик" к этой временной таблице, который возвращает ОДНУ запись.. "exec sp_executesql N'SELECTT1._IDRRef,T1._DescriptionFROM _Reference84 T1 WITH(NOLOCK)WHERE T1._IDRRef = ',N' varbinary',0x84220015175FB50811DD75916EA35E0B Дергать sql-сервер такими запросиками - извращение.

Код 1С покажи.

в платформе 1С не сделали нормальную реализацию паттерна "итератор"

а где тут временная таблица?

к

Это больше похоже на вызов Сообщить(Выборка.Ссылка)

Пардон.. про временную таблицу соврал. Однако про микрозапросики - факт.

>> vi0 И для метода Выборка.Следующий профайлер молчит Потому что данные уже на сервере 1С

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

Вот с выборкой Вариант 1: А вот с таблицей значений Вариант 2: В случае варианта 1 sql-сервер задрачивается мелкими запросиками. В случае варианта 2 - выдает данные одним селектом. Что лучше?

Вот источник микрозапросиков. Стыдно должно быть

Для 2 варианта, Табличка скорее всего кэширует Представление для сортировки.

То есть, суть в получении представления?

Дык зато на SQL-сервере память не будет держаться.

да.

Да что разработчики знают о масштабируемых решениях? Они даже нагрузочное тестирование типовых конфигураций произвести не могут...

Вау, мой уровень телепатии поднялся на 1 уровень )))

Разработчики платформы к типовым отношения не имеют.

Во-во, разрабатывают сами для себя что-то в вакууме... убил бы.

Для вас ведь стараются. Чтоб вы денег зарабатывали.

Мне за державу обидно ;)

в платформе не сделали нормальную реализацию mapreduce

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

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

да кто мешает? речь не об этом. Выборка неизменяемая (immutable по-научному). А ТЗ - изменяемый (мутабельный) объект. immutable-объекты легче и проще в реализации. это аксиома. т.е. если не нужно изменять саму коллекцию, то и не нужно загонять ее в изменяемый объект.

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

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

+52 к тому же она на клиенте не доступна

еще точнее на тонком и вебклиенте

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

изменять существующую коллекцию хуже, чем создавать новую

Ну, например, надо выйти на родителя по цепочке до корня. Организуй запросом. Или надо обратиться к предыдущей/следующей строке. Или надо поменять тип поля. Да и многие более простые задачи требуют либо открытия нескольких выборок (и головняка с их синхронизацией), либо выгрузку в ТЗ и ее обработку. По времени разработки второй вариант может оказаться меньше - ну а скорость работы... лучше плохая, но работающая программа, чем идеальная, но несуществующая. За первую заплатят, за вторую - нет. Даже авторы типовых используют выгрузку в ТЗ в некоторых случаях. Т.е. лучше потратить в 2 раза больше памяти копируя одну коллекцию в другую? Вообще-то, изменение состава коллекции - самая затратная по ресурсам вещь, а вот изменение элементов коллекции - уже гораздо менее затратная. А в случае Выборка.Следующий и создания ТЗ изменение состава будет при каждой итерации цикла.

Выборку не юзаю, ибо ее отладка - это п.ц

>> Или надо обратиться к предыдущей/следующей строке НайтиСледующий(<СтруктураПоиска>) СледующийПоЗначениюПоля(<ИмяПоля>) У Выборки, кроме Следующий еще и такие методы есть.

Пролетел гордый орел, плавно машущий крыльями, с высоты обкакав фирму 1С. Орел чуть стушевался, но пока настаивает на том, что он орел. Орел не орел :)) Штатный дворник фирмы 1С привычными движениями флегматично подметает крышу фирмы :))

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

Ну и зачем весь этот словесный понос? Форум для обсуждения 1с, а не его участников.. Ошибку же я признал. Тем не менее, поведение 1с в данном аспекте весьма неочевидно.

Москвичи..  всё-таки крайне неприятные субъекты в 90% случаев) Обхами ближнего и пройди по головам - вот их лозунг.