Допустим, есть список договоров. В периодическом РС нужно отобрать накладные оформленные по договору из этого списка.
Есть три варианта:
1) внутреннее соединение списка договоров с "выбрать последние"
2) указать в параметрах виртуальной таблицы условие типа "Договор в (подзапрос к списку договоров)"
3) Указать условие в предложении "Где" - Договор в (подзапрос к списку договоров)

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

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

я тестировал пару лет назад, баш на баш

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

протестируй разные варианты на своих данных
добавляй индексы и т.д.

(0) Если Договор это измерение в РС, то 2)

http://its.1c.ru/db/metod8dev#content:5842:hdoc

(1) Нерекомендацию в студию. Левое соединение с подзапросом - да, видел недавно.

(6) О. она.

(7) http://its.1c.ru/db/metod8dev#content:5842:hdoc:subquery_join

постгре от соединения со срезом последних умрет 146%

(9) А насколько это все актуально сейчас, кто может сказать? Со времен 8.0-8.1 оптимизатор скуля (да и других СУБД) шагнул вперед. В частности, с определением кардинальности подзапроса (из-за чего, как я понимаю, весь сыр-бор) справляется вроде неплохо.

(11) недавно переделал запрос по партиям в упп (поиск рулит)
Скорость возросла в 4 раза.

(0) запусти оба на практике, посмотри планы запроса и, который дешевле, тот и выбирай.




Но в общем случае, я бы подзапрос даже не рассматривал.

(0) Статистика - рулит. В случае вложенного запроса - статистика может захромать, в случае темпов - нет.

+ в случае Внутренного соединения - можно писать просто СОЕДИНЕНИЕ. Ибо это - по JOIN по умолчанию

(14) Статистика по временным таблицам всегда собирается автоматически?

(12) Как лучше, внутреннее соединение или подзапрос в условии?

(16) полагаю, что дело тут не в "автоматически", а в том, что темпы по определению меньше живут (максимум в пределах одного сеанса), и статистика по ним просто не успевает деградировать. В 1С, где функционал темпов ограничен SELECT INTO  и DROP TABLE (нет ни добавления ни обновления записей) - и подавно.

(16) полагаю что вообще не собирается

видел пример когда соединение вложенных запросов работало быстрее чем создание 2х временных таблиц и их соединение.

причем именно из за статистики.

(18) Я имел в виду другое. После создания ВТ через ПОМЕСТИТЬ статистика у нее будет? Если данных в ней много и они скошенные, оптимизатор не может ошибиться так же, как с подзапросом?

(20) нет

статистики не будет
имя таблицы что то типа #673

(20) Будет статистика. Она создаётся при создании таблицы.

(20) Согласен с (23)
Немного заяндексил, наткнулся на любопытную статью:
http://www.sql.ru/articles/mssql/2005/081301statisticsinsqlserver2005.shtml
Сильно пока не вникал,  но понятно, что  статистика для темпов - есть)
Упоминаются параметры БД  AUTO_CREATE_STATISTICS и AUTO_UPDATE_STATISTICS

(6) Использование логического ИЛИ в условиях

а сами его используют в исправлении

Получение данных через точку от полей составного типа

(24)
ошибся может, спутал с табличными переменными, но когда смотрел планы запроса, они не зависели от содержания таблиц
К тому же кеш планов запросов все равно работать не будет.
а время компиляции запроса может быть больше работы с ним если там десяток строк
http://billibook.blogspot.ru/2012/07/blog-post_21.html

(25) Покажи пример где они ИЛИ используют

добавлю яда против ВТ

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

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

по этому при построении  соединения запросе нужно понимать 2 вещи
1. все-ли типы параметров имеют явно приведённую типизацию
2. условие в соединение позволяет или нет использовать индексы

все остальное - фигня, все эти рекомендации 1с (из 6) это для чайников... так сказать "общий случай"

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

(28) *ВТ часто хромает неопределенным или сборным типом (например регистратор)*
Это никоим образом не является проблемой ВТ. Это проблема исключительно кривых рук.

(30) это проблема когда все без разбора пихают в ВТ...

а когда руки прямые - глубоко пофиг что это будет ВТ или подзапрос...

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

(31)
Доводы, которые вы привели, не имеют абсолютно никакого отношения к выбору между вт и вложенными запросами.

Потому что - типизация - определяет текст запроса (количество соединений) - который построит платформа 1С при выполнении своего запроса (диалекта 1С)
Это тема из другой оперы вроде как.

*а когда руки прямые - глубоко пофиг что это будет ВТ или подзапрос...
*
Это да, потому что прямые руки всегда будут использовать наиболее эффективный способ.

(32) + Касаемо т.н. разыменования полей, которое неминуемо превращается в проблему неявных соединений- я считаю это зло. Потому что РегистраторТочкаНомер - это зло. Разработчик должен четко понимать какие таблицы он цепляет в свой нетленный запрос и для чего.

(27)

Запрос.Текст = "ВЫБРАТЬ
| ВЫБОР
| КОГДА Продажи.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг
| ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.РеализацияТоваровУслуг).Номер
| КОГДА Продажи.Регистратор ССЫЛКА Документ.ЗаказПокупателя
| ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ЗаказПокупателя).Номер
| КОНЕЦ ВЫБОРА КАК Номер,
| ВЫБОР
| КОГДА Продажи.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг
| ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.РеализацияТоваровУслуг).Дата
| КОГДА Продажи.Регистратор ССЫЛКА Документ.ЗаказПокупателя
| ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ЗаказПокупателя).Дата
| КОНЕЦ ВЫБОРА КАК Дата,
| Продажи.Контрагент,
| Продажи.Количество,
| Продажи.Стоимость
|ИЗ
| РегистрНакопления.Продажи КАК Продажи
|ГДЕ
| Продажи.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг
| ИЛИ Продажи.Регистратор ССЫЛКА Документ.ЗаказыПокупателя";

(34) я так полагаю это не все параметры и там будут еще условия по периоду и еще что-то, а это уже другая тема

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

(34) лично я (имхо) - вместо выразить(.Номер) - сделал бы явные соединения с таблицами, и поле запроса было бы isnull(ДокРеализация.Номер, ДокЗаказ.Номер). Было бы гораздо нагляднее, что куда цепляется и что откуда берется. Жаль, что coalesce - 1с не умеет.

(37) тут про ИЛИ в ГДЕ, одно исправили, а запрос не разбили:

Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероянтность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты.

(36) этого текста мало
скорее всего это текст из отчета на СКД, и конечный запрос будет другой

(39) это конечный запрос

(40) если конечный, то в чем конкретно проблема?
не теоретически, а на рабочей базе какая проблема?

(38) не очень понятно, причем здесь блокировки, это уже частный случай.
В целом - согласен, конечно. Опыт был, когда запрос с ИЛИ тупил, и банальное разбиение оного на ОБЪЕДИНИТЬ - ускорило выполнение  в разы.  Но, опять же, это не имеет отношения к теме.
Если есть желание обсудить оптимальность запросов - можно затронуть непростую тему списков с отборами.

(41) (42) прочтите оба уже по ссылке из (6)

(43) Ссылка известная. Конкретизируйте пожалуйста свой пассаж.

(43) так я тебя не про теорию спрашивал, а в чем у тебя была проблема с этим запросом?
какое назначение этого запроса?

(44) (45) мы обсуждаем текст из (6), в котором противоречие

(46) В чем заключается это противоречие?

(46) ответа у тебя нет, я понял

(47) + наверное в этом: "Следует соединять друг с другом только объекты метаданных или временные таблицы."

Только - это ключевое слово. Похоже на то, что одинэсы реально упоролись со своим разыменованием

(49) я уже написал в чём противоречие, в одном месте указали как ошибку, в другом использовали как исправление
(48) ответа на что? есть методичка в (6), в ней ошибка, что тебе ещё объяснить?

(50) в методичке сказано, что ИЛИ не позволит испоьлзовать индексы
а какие индексы предполагалось использовать в запросе (34)
и предполагалось ли?

(50) на этой странице есть четыре вхождения слова "противоречие" одно из них моё, это был вопрос. И три - ваши. Все три - без конкретики.  Личн я не воспринимаю слово "противоречие" - как мантру, как заклятие, как молитву. Для меня это конкрентное слово с определенным смыслом. Хотелось бы, чтобы вы конкретизировали (или указали конкретный пост)  - к чему вы это слово употребили.

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

(52) см (25)

(54) причем здесь противоречие???

(53) я и спрашиваю - предполагалось ли использовать индексы в этом запросе?
какую задачу решает этот запрос?

(55) + это банальность. Вы же говорите о противоречии. Противоречие -  Чего с чем?

(55) в "Получение данных через точку от полей составного типа" они не разбили "правильный" запрос на два, как рекомендовали в "Использование логического ИЛИ в условиях"

(58) пока еще не сильно вдаваясь, но по примеру:
ВЫБРАТЬ Товар.Наименование ИЗ Справочник.Товары КАК Товар ГДЕ Артикул = "001" ИЛИ Артикул = "002"
Наглая ложь.
Потому что ИЛИ деградирует план запроса только если оно касается РАЗНЫХ полей. Этот же  запрос оптимизатор легко преобразует в Артикул В ('001', '002'). Все имеющиеся индексы будут задействованы.

(58) конкретную цитату можете привести?

(60) см (38)

(61) см (60)

(61) +
Я уже понял, что вы настойчиво отправляете нас к этой ссылке. Хотелось бы услышать, зачем вы это делаете, какую мысль вы пытаетесь донести. Непонятно.

(63) потому что я писал именно про неё

(64) Про неё? Она - это кто?

(65) ссылка в (6)

(66) понятно. Твоя ссылка - г_вно.

(67) это не моя ссылка, а 1с

(68) Ты эту ссылку привел, а значит эта ссылка - твоя. Ты на нее - сослался (вот тоже слово блин) как минимум.

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