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


или


Как лучше?
Или очень ли плохо собирать именно во временную таблицу, хотя использоваться она будет локально в одном скрипте, а по его завершению удаляться? Мне "организационно" удобнее использовать временные таблицы, но если так "невынужденно" дёргать диск это совсем-совсем плохо, то переделаю

msLexА что, из вами приведенного, является "табличной переменной"? Уж не "as" ли?

Ага, оно - "as" ли :)) Но Вы же догадались о чём я? Не знаю, что это и как называется. Плохо, понимаю. Показалось похоже на переменную, и что "оно" in memory.

Но это не снимает вопрос, а усиливает, подчёркивая уровень вопрошающего.
Чем бы оно ни было, это "as" ли :)) - мне к нему повторно обращаться не нужно. (Хотя если кто-нибудь скажет, что это, будет полезно)
Так вот когда к временной выборке повторно обращаться не нужно, она сразу после отработки скрипта будет удаляться, будет ли при этом сильно плохо использовать select into? Или это ни для чего особо не критично?

просто именованная выборка?

PizzaPizzartv,

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


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

fkthatrtv,
Это называется "derived table" и никакого отношения к временным таблицам или переменным не имеет. Временная таблица или табличная переменная - это вполне реаьная материальная таблица в tempdb, а derived table это просто синтаксическая конструкция в запросе - никаких физических таблиц, как и при использовании CTE, при её использовании не создается. fkthat, Спасибо!

PizzaPizzaЛюбые вещи нужно использовать по назначению, т.е. если они нужны. Зачем вам временная таблица?
fkthatrtv,
Если есть возможность использовать derived table или CTE, то надо использовать их, т.к. это даст больше простора оптимизатору поработать над твоим запросом.
В большом select используется некая промежуточная выборка, организованная как "derived table".
Сейчас нужно, по условиям использовать в этом месте разные выборки. Вроде как напрашивается введение переменной. С точки зрения моего внешнего кода (Delphi) именно так было бы правильно. И вот встал вопрос, насколько это будет хуже относительно уже кода sql. Ну по итогам обсуждения "моё подозрение" подтвердилось - нагрузку на сервер "просто так" - это плохо, у оптимизатора будет меньше свободы, тоже плохо.
А поскольку я пишу в Delphi мне не надо будет усложнять запрос ещё и этим условием на разные выборки. Я без проблем динамически сформирую разные запросы по каждому условию для этих промежуточных выборок. Временные таблицы всего лишь повысили бы мне читабельность моего дельфийского кода, но это не аргумент.
Всем спасибо!

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

PizzaPizzartv Временные таблицы всего лишь повысили бы мне читабельность моего дельфийского кода, но это не аргумент.
Читаемость кода это СТЕ. Прочитайте про них. Они никак не влияют на фактическое выполнение запроса, а только на его отображение - на текст.
Спасибо. Читаю. Полезно.
Но я то про другое вообще, про дельфийский код, который к этому разделу отношения не имеет.

Руслан Дамировичrtv,
в вашем случае читаемость повысила бы "инкапсуляция" кода SQL в процедуру и ее вызов из программы на Delphi.
А в самой процедуре уже хоть временные таблицы, хоть табличные переменные, хоть табличные функции. Процедуру на сервере? Нет, это не "наш случай", к сожалению. У нас код правится постоянно (сверху поступают новые регламенты в режиме потока сознания), такая жизнь ;). А оперативность внесения изменений в приложение выше, чем на сервер.