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

(0)
Колонку поиска не стоит индексировать.

(1) Почему?

(0) Померяй.

(2) Моего слова тебе недостаточно?

(4) неа

(5) Я не с тобой разговаривал.

(0) <Часто возникают ситуации, когда нужно поискать что-нибудь в результатах запроса>

А для чего тогда запрос?

(4) Ты миссионер что ли? Знаешь - объясни, а на слово верить - это к журналистам :)

(6) а мне до ширинки, с кем ты разговаривал.
Обосновывай утверждение. Или слив считаем.

(4) С каких пор ты стал истиной в последней инстанции?
Экзамен сдал и зазвездился чтоли?

(1) еще как стоит... проверено 100%

(7) Для того, чтобы сформировать выборку в памяти.

У нас ту не клуб джентельменом, мы на слово не верим

(4) корона не жмет ?

(12) И потом по ней ещё раз искать чтото? Бред.

(4) О Великий! Твоего слова достаточно чтобы вода стала вином! Не слушай простых смердов!

(10) Хехе, отлично.

(15) Пожалуйста вам:
Загрузка данных из файла, при том, что часть данных(но не все!) уже существует в БД. Ищем данные запросом по ключам, если в результате запроса есть такие данные, то подставляем из результата запроса, если нет - создаём. Предложи, как решить эту задачу ТОЛЬКО запросом.

(7) например, в ПриПолученииДанных получили набор свойств, их потом заполняем оформление строк.

Индексировать стоит в большинстве своем только долгоживущие данные.

Если число поисков по таблице мало - смысла индексировать нет.
Если число поисков по таблице велико (большая внешняя таблица) - проще обойти эти 2 таблицы в одном цикле (merge join).

Все, согласно классике.

(20)я так понял тс ищет неоднократно, так что проиндексировать все таки смысл есть

(21) Я думаю - проще обойти в одном цикле эти 2 отсортированные предварительно таблицы и сформировать массив найденных строк-совпадений.

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

(18) Данные из файла в ТЗ, ТЗ в запрос с джойнить с номенклатурой, обойти и записать

(19) СКД многое умеет

(23) Офигенный замут. Только кто сказал, что в данных только номенклатура?

(24) в оформление по условию

(25) Да пофиг с чем сравнивать и соединять

(17) Понравилась реакция Гёдзы. Надеюсь, это немного поможет ему более человечнее общаться на этом форуме.

(23) самый простой пример: Нужно в списке номенклатуры/(обычные формы) видеть свойства(2-3 штуки) из РС ЗначенияСвойствОбъектов.
аналогичное может требоваться в ТЧдокументов, списках документов итд, вместо этого РС может быть другая связанная информация.
варианты "переходите на 8.7.125, там это реализовано" не предлагать

Моё мнение все можно сделать в запросах и не делать лишних циклодвижений особенно для какой-то выборки по условия, а если нельзя, значит не удачная реализация структуры БД. Зачем напрягать приложение если СУБД сама все может сделать?

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

(0) а это:
3. ТЗ в ВТ и запросом к ней?

(30) СУБД может кончиться.

(30) Можно, вопрос как лучше. Мне решение с запихиванием ТЗ в ВТ не представляется лучшим. По сути ты вместо выборки данных и поиска в памяти - сначала пишешь в базу, потом начинаешь из этой же базы выковыривать. Причем либо генеришь индекс(что тоже - время), либо ищешь в куче, без индекса. Офигенно оптимальное решение. Зато сервер приложения не напрягается.

(29)И в чем проблема?

(34) Ну крутите в циклах

(36) Не, ну циклы - это "бред", как мы узнали из (15).

Сделайте какую нить массовую начислялку, покрутите и сколько это время у вас расчет

займет

Сервер СУБД нужно холить и лелеять - он один и больше не предвидется. Серверов 1С может быть побольше одного (хоть это и плохо из за синхронизации) - можно их озадачить. Но вот клиентов - дозвизды, как правило на относительно мощных машинах - вот их стегать и надо. Особенно если эти поиски вне транзакции.

(40) А нафига сервер тогда нужен? Зачем клиент сервеная аритектура??

(41) Она трёхзвенная, вообще-то. Вот СУБД нефиг делать, только всякий мусор во временных таблицах сохранять по 100 раз на дню.

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

Ещё раз повторюсь МОЁ, сугубо скромное, пройденное опытным путем в массовых начислений и оптимизации их, мнение все можно сделать и нужно на запросах, особенно всякие условия отбора!!! Приложение только для отображение полученных данных в формочках.

(43) клиентов, если возможно

(43) Думаю, в каждом конкретном случае надо думать. Зависит от условий поиска и количества данных, а также от описанного в (40) соотношения. Может у тебя клиенты дохлые совсем.
(44) СЛОЖНЫЕ условия - согласен, проще запросами. Простые - нет.

(43) Клиента. Правда очень редко его напрягешь, так как чистых вычислений и нет толком - все завязано на работу с данными.

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

(48) Ты, походу, многого не знаешь о трехзвенке :-).

(48) В типовой УПП документы проводятся на клиенте.
Да, есть серверные блоки проведения.
Но есть и клиентские.
Учите 1С должным образом...

Предупреждая буквоедов:
1) да, есть Управляемый режим.
2) да, проведение документа можно вызвать из серверной процедуры в Обычном режиме.

(48) в обычном приложении толстого клиента и так на клиенте проведение)

(20) Индексировать есть смысл в любом случае. Случаев когда индексировать не нужно не существует.

(53) Продолжайте индексировать в любом случае.

(22) Да ты обкурился...

(50) горбатого лепишь, вся запись в регистры делается на сервере, а это 80% нагрузки на БД, сами вычисления копейки по нагрузке

(51) а что такое клиентские блоки проведения?

(0) посмотри как сделано в типовых

(57) Например, формирование проводок в процедуре
ДвиженияПоРегистрамРегл() документа РТУ.

(57) systemstopper , ты, щтоле?
Давай, досвиданья.

(50)(52) это временно, переходят на сервер

(68) Конечно в управляемом перейдут на Сервер.
Но не потому что так быстрее.
А потому что так "не медленнее", чем в Обычном.
Почему?
Потому что XDTO.

(68) сам процесс записи естественно через сервер 1с на субд идёт, но также идёт передача всего объёма информации с клиента на сервер 1с, уже готового. Само формирование этих записей - на клиенте