Коллеги, на ваш взгляд, виртуальные таблицы предпочтительнее подзапросов?
Методисты 1С отвечают, что использование виртуальных таблиц в любой дырдочке невероятно полезно для здоровья. Я сомневаюсь только в одном: создание виртуальной таблицы блокирует tempdb (как мне кажется, но этот факт я не проверил), а она, как известно, одна на всех.
Следовательно она может стать узким местом, став востребованным конкурентным ресурсом про большом количестве одновременно выполняющихся запросов.
Как оно на самом деле?

Если вы знаете, что такое view в СУБД, то поймете, что такое виртуальные таблицы. И только через виртуальные таблицы имеется доступ к таблицам итогов.

Тваюмать, я имел вввиду ВРЕМЕННЫЕ !!!

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

(3) Спасибо за ответ.

Каковы вытекающие последствия от перехода к частично процедурной парадигме?

От чего зависит результат времени выполнения запросов?
Если запросы через временные таблицы могут быть как быстрее, так и медленнее, как определить правильный метод построения, исходя из конкретной задачи и ситуации?

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

(0) оттрейси запрос со временной таблицей - шибко удивишься.

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

Сам придумал?

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

http://kb.1c.ru/articleView.jsp?id=44#subquery_join

(7) Так и есть. Особенно часто бывает неоправданное применение nested loop join. Жаль, что в языке запросов 1с отсутствуют хинты - подсказки sql-серверу.

Временные таблицы - наше все.

(0) >>создание виртуальной таблицы блокирует tempdb
tempdb не блокируется. Для создания таблицы не нужен "монопольный" доступ. Создавая временную таблицу вы, фактически, создаете таблицу в базе данных tempdb.
(8) И что бы вы посоветовали оптимизатору? Использовать hash join? Или merge join? Учитывая тот факт, что платформа не предоставляет возможности полноценного управления индексами, это даже хорошо, что у 1С-ников забрали возможность использовать возможность "подсказать" оптимизатору (я это не конкретно про Вас говорю).

(7)
Правда ведь, что "оптимизатор выбирает очень неоптимальные методы" и "СУБД может ошибиться с выбором плана" - это две большие разницы?

(11) Чукча не читатель, чукча писатель?

В вопросе дословного соответствия терминологии фактическому поведению СУБД я доверился пользователю "Chai Nic".
Задавая ему вопрос в посте (4) на ответ в посте (3), я придерживался заданной терминологии, процитировав части его сообщения в целях достижения лучшего взаимопонимания.

Если вам нечего сказать по делу, а именно:

От чего зависит результат времени выполнения запросов?
Какие еще факторы влияют на план выполнения запроса?

Разумеется, вопросы следует рассматривать в контексте текущей темы, а именно, влияение временных запросов на производительность в многопользовательской среде.

Например, пользователь "Шляпентох" дал ответ в посте (10), вактически сняв вопрос темы, хотя и не подтверждая аргументы авторитетными источниками.
А пользователь "Себастьян Перейро" дал очень дельный совет, в посте (5) которым я воспользуюсь, потому, что я люблю удивляться.

1)А зачем вообще делать многоэтажные запросы?
К тому же, как выясняется, добрый дядя оптимизатор при этом решает какие-то свои проблемы.
2) К тому же, расчленение запросы на несколько подзапросов (с хранением промежуточных результатов) в таблицах или деревьях) позволяет провести дополнительную фильтрацию следующих запросов и резко сократить вычисления.
3) И самое главное: декомпозиция запросов позволяет ДОКАЗАТЬ, что программа работает правильно, что в случае многоэтажных запросов - совсем не очевидно.

(13) Спасибо за ответ. По всем пунктам вы правы, я с вами абсолютно согласен.
Вопрос касается интенсивной работы нескольких пользователей. Не будут ли они блокировать друг друга?

Что касается tempdb, SQL можно настроить на обслуживание нескольких приложений. В таком случае, если стороннее приложение блокирует tempdb, производительность будет снижаться?

Есть такое понятие - зона ответственности.
Когда я пишу программу, то я знаю, что если выберу простой квадратичный алгоритм, то он когда -нибудь займет несколько часов на свою работу, а если выберу сложный
O(n*log(n)), то он будет считать минуты.
И это - полностью зависит от меня. А программа эта будет работать у кого-то в файловом режиме, у кого-то под sql, а когда-нибудь всякие толстые-тонкие клиенты появятся, диски SSD и т.п. Но это все - не моя зона ответственности, а инженеров и администраторов баз данных.
Поэтому не следует придавать слишком большого значения всем этим системно-зависимым вещам, включая tempdb и тому подобное: то, что зависит от меня, как правило, имеет значимость на порядок более важную.

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

(15) а вдруг это самое важное.. попробуй.. :))
а по сути если с таким отношением подходить к написанию кода, то апгрейд серваков надо будет делать раз в неделю... после написания 2-3 новых отчетов..

(12)Про чукчу не могу сказать писатель он или читатель, спросите у него...

Chai Nic писал как раз про неоптимальный выбор в "некоторых случаях" , а не о том что это происходит в любом случае, если "если ... не известно заранее, сколько записей вернет запрос."

Что такое "временные запросы" я не знаю, это какой-то местечковый термин...

Ссылки, подобные http://kb.1c.ru/articleView.jsp?id=44#subquery_join лучше не давать, ибо они доступный не для всех...

Предпочитаю первоисточники вроде этого: http://msdn.microsoft.com/ru-ru/library/ms175527.aspx

(16) Напротив, я стараюсь писать надежный и быстрый код, не перекладывая оптимизацию на компилятор или среду выполнения. К тому же, мои пользователи зачастую в файловом режиме работают на слабых компьютерах, декомпозиция запросов (из стандартных конфигураций) иногда и дает выигрыш на порядок.

(15)
Про спортсменов - А ЗАЧЕМ? O_o

(19) А вдруг победят, придется на пьедестале почета стоять.. а тут такой непорядок)

(19) Сопротивление воды стараются уменьшить всеми доступными средствами: это когда все остальные уже использованы.

(19)В свое время были опубликованы результаты исследования, которые гласили, что "полное удаление волосяного покрова с тела спортсмена снимает (в среднем) 1,7 с на стометровой дистанции". Однако не было доказано, за счет чего это происходит, большинство считает, что это психология...

(21) Не бось еще ногти в ноль вырезают + камнем пятки вычищают до костей )

tempdb - и есть те самые "волосы".

(10) "И что бы вы посоветовали оптимизатору? Использовать hash join? Или merge join?"
Как правило, hash join работает лучше на типичных для баз 1с данных. По крайней мере, в постгресе глобальное отключение nested loop приводит именно к этому методу.. и в частности в ЗУП это значительно ускоряет расчет зарплаты, в разы и десятки раз. Допускаю, что в других местах может быть замедление.

(14) Кто вам вообще сказал, что tempdb кто-то блокирует? При активном ее использовании ей требуется определенный уход - вынос на быструю дисковую подсистему, настройка initial size и т.д. Что до авторитетных источников - изучайте bol, ищите best practices по tempdb.

(26)База tempdb блокируется при создании таблиц в ней... Если, к примеру, использовать для создания временной таблицы конструкцию SELECT INTO... с большим количеством записей, то получение "удовольствия" гарантировано...

(27)
Блокируется буквально на милисекунды в момент создания ВТ, а не в момент помещения записей.

(0) В юбом случае.
Естествено, что есть накладные расходы на создание и уичтожение ВТ но они не сопоставимы с тормозами, возникающими при отработке неоптимального плана.

Да и индексировать ВТ -  крайне полезное занятие.

(27) http://www.youtube.com/watch?v=PS41crF1GUs
Никаких блокировок. Осторожно, трафик.

Есть хорошая книжка "Оптимизация SQL", советую почитать.

Для временных таблиц важен:
1) Порядок и селективность полей
2) Количество записей
3) Возможность кэширования результата.

В 1С есть одна штучка, которая считается ошибкой: это выполнение запроса в цикле, но иногда без него не обойтись - например в сложных итерационных вычислениях.
Так вот, использование парочки небольших проиндексированных временных проиндексированных таблиц для условий отбора - позволило сократить в 10 раз время расчета. Но пришлось повозиться и с индексами и со структурой базы.

Дополнительно созданные индексы в базе SQL для таблиц, позволяют тоже в несколько раз ускорить работу запроса, но это  хорошо, когда структура не меняется долгое время.

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