Параметры в хранимых процедурах в выражении SELECT

Доброе время суток.

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

Например

SELECT ...
FROM ....
WHERE NAME = @PARAM

Интересно, а можно-ли использовать текстовый параметр, который будет просто 'дописываться' в нужное место запроса?

Например:

SET @PARAM='ORDER BY NAME ASC'

И потом написать запрос:

SELECT ...
FROM ....
@PARAM

Т.е. получить выборку, упорядоченную по имени.

Или для этого можно только формировать нужную строку с запросом и потом выполнять запрос командой EXECUTE?

0

EXEC 'SELECT ... FROM .... ' + @PARAM

0

Про ехес понятно...

Только выполняется он дольше и формировать эту строчку муторнее.

А другим способом динамически формировать условие запроса (например, ORDER BY) нельзя? По типу как я выше писал...

0

Нет.

0

Кстaти, a чем вызвaнo утверждение чтo дoльше выпoлняется?

0

Читал в какой-то книжке про MS-SQL об этом. Где и когда и почему - не помню.

0

Я думaю чтo речь тaм шлa не oб EXECUTE a o dynamic SQL в целoм.

0

Параметры в хранимых процедурах в выражении SELECT

Согласен с Mike_R. Речь идет о том, что любой SQL-запрос, в том числе и динамический, проходит перед своим выполнением след. стадии:
- проверку синтаксиса
- парсинг
- проверка прав доступа к объектам, на которые ссылается SQL-запрос
- поиск плана выполнения в cache
- создается план выполнения
эти действия выполняются каждый раз при вызове SQL-запроса, exec @sql_string и при СОЗДАНИИ хранимой процедуры, но НЕ ПРИ ЕЕ ВЫПОЛНЕНИИ (!!)
т.е. каждый раз вызывая хранимую процедуру SQL-Server не проводит эти стадии.

если exec @sql_string вызывается из хранимой процедуры, то SQL-запрос (находящийся в @sql_string) должен пройти эти же стадии прежде чем его результат/управление вернется в хранимую процедуру.

Вот это и есть разница в скорости выполнения.

p.s.: время выполнения этих 5и стадий значительно меньше времени выполнения самого запроса. (десятки, сотни, тысячи раз)

0