Почему вы хотите избежать динамического SQL в хранимой процедуре?


13

Я слышал, кто-то сказал, что вы не хотите использовать динамический SQL. Можете ли вы привести конкретный пример или пример из реальной жизни? Лично я несколько раз кодирую это в своей базе данных. Я думаю, что это нормально, потому что это гибкость. Я предполагаю, что SQL-инъекция или производительность. Что-нибудь еще?

Ответы:


7

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

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

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


5

Динамический SQL - это инструмент. И как инструмент, у него есть несколько приложений - для административных работ это, например, благословение.

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

Я не буду вдаваться здесь в подробности, поэтому я рекомендую отличную статью о проблемах динамического SQL: Проклятие и благословения динамического SQL. Автор MVP Эрланд Соммарског.


1
Я собирался поделиться этой ссылкой, она должна быть прочитана для всех, кто рассматривает возможность использования динамического SQL.
HLGEM

1

Это похоже на большинство функций dbms: если вы используете его в правильной ситуации, он хорошо работает, в неправильной - плохо.

Плюсы: некоторые вещи просто невозможно сделать без этого. Обычно я обнаружил, что это только для административной работы, а не для кода приложения. Некоторые системные команды не позволяют использовать параметры в качестве входных данных. Так, например, если мне нужно выполнить что-то через sproc для каждой базы данных, во многих случаях с неизвестными базами данных, и команда не принимает параметры, я обычно решаю это с помощью динамического SQL. Однако в Sybase ASE это больше, чем MSSQL.

Минусы: я не буду вдаваться в подробности, так как я думаю, что мы все уже знаем это, но может быть некоторый риск для внедрения SQL, если он используется неправильно. Для меня более важным является то, что запрос будет обрабатываться так, как он есть, уникальный запрос adhoc, а не часть плана скомпилированного запроса. Для чего-то, что иногда работает, ничего страшного. Для чего-то, что выполняется сотни раз в минуту и ​​будет иметь много уникальных sql, это сгенерирует много новых, потенциально ненужных, планов запросов с истощением циклов и сокращением допустимого времени кэша плана.


Отличное применение приложения в Sybase ASE - это разворот без знания значений, которые нужно повернуть. Это можно сделать с помощью динамического SQL в хранимой процедуре, но, насколько мне известно, Sybase ASE не поддерживает синтаксис для выполнения этого непосредственно в качестве запроса. Только когда значения известны, запрос может быть записан для поворота данных.
Ричардкроссли

-7

Не используйте динамический SQL.

99% времени Динамический SQL используется из-за отсутствия знаний о том, как использовать необязательные параметры в хранимых процедурах, остальное 1% времени используется для создания очень сложного запроса для отчета, который клиент не понимает даже. Проклятие и благословения динамического SQL не показывают пример того, почему было бы неплохо использовать его, вместо этого просто предлагает, что это проблематично, потому что это усложняет отладку, обслуживание, не говоря уже о рисках безопасности SQL Внедрение, низкая производительность не потому, что кэш, а плохие методы, которые идут с ним, такие как использование временных таблиц и курсоров, которые, конечно, ленивы и наивныПрограммист будет злоупотреблять. Не существует такой вещи, как гибкость написания запросов таким образом, SQL является декларативным языком, и его следует рассматривать как таковой.

Лень - корень всего зла.

Как это ни парадоксально, но этот ответ оценивается как наиболее отрицательный .


В действительности, в статье предлагается, по крайней мере, один пример идеального варианта использования для динамического SQL, и «не существует такой вещи, как гибкость в написании запросов таким образом ...», это не так - динамический SQL - это именно то, что позволяет гибкость.
LowlyDBA

Необязательные параметры? Вы имеете в виду антипаттерн?
Форрест

@LowlyDBA В статье предлагается, по крайней мере, один пример: самый простой SELECT из когда-либо виденных, что за сложная проблема это решение? и для гибкости, да, для тех наивных программистов.
Иванзиньо

@ Forrest, почему ты называешь это "антипаттерном"? потому что указанная вами ссылка никогда не говорит об этом, а также никогда не показывает, насколько было сделано улучшение после того, как логика была переписана в Dynamic SQL (что в этом случае было бы незначительным по сравнению с эффектом «снежного кома» от поддержания этого запроса в конечном итоге)
Иванзиньо

Это (плохой) основанный на мнении ответ ИМХО. Вы не предоставили конкретных примеров проблем, которые вы описали, и не определили
преимущества
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.