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

Question

Я читал книгу по SQLServer 2008. В этой книге автор заявил, что, хотя хранимые процедуры являются в основном решением, вам следует избегать их постоянного использования.
Я знаю, что хранимые процедуры предварительно скомпилированы, что какрезультат заставляет их работать быстрее, чем обычные команды.Кроме того, поскольку они используют параметры для передачи данных, они намного безопаснее, чем обычные команды SQL в случае атак с использованием SQL-инъекций.
Так что я не понимаю: Почему не всегда используются хранимые процедуры?

Answer 1

Хорошая статья на эту тему

http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html

Так что я думаю, что вы должны делать то, что предпочитаете. Разницы в производительности нет (для msot запроса вам придется выполнить).

Я бы сказал, что нет хранимых процедур: хранимые процедуры - это боль ..:

• без перегрузки: если вы хотите добавить параметр, вам придется обновить все ваши вызовы (или создать новый SP)

• нет сложного типа: с динамическим SQL вы можете построить все ваши фильтры SQL, как вы хотите, в зависимости от ваших сложных объектов

• securiy не является причиной: если ваш sql-запрос защищен от инъекций sql и ваша база данных доступна не для всех, вы можете управлять своей политикой безопасности доступа к данным на уровне приложения (любой dba убьет меня, говоря это но любой разработчик согласился бы ... я думаю)

SP "предварительно скомпилированы" (при первом выполнении сервер базы данных найдет лучший план выполнения для SQL-сервера), НО в наше время мы можем забыть об этом, время "компиляции" действительно мало нам не нужно беспокоиться об этом. Я никогда не сталкивался с ситуацией, когда я думал, что "OMG, время компиляции является узким местом моего приложения", большую часть времени узким местом вашего приложения будет сам запрос, поэтому не беспокойтесь о производительности, когда вам это не нужно.

И эта «предварительная компиляция» зависит от параметров, которые вы отправляете в SP (при первом вызове), поэтому иногда вы можете иметь много проблем с производительностью (называемых «анализом параметров») с SP (см. Здесь: http://www.sqlpointers.com/2006/11/parameter-sniffing-stored-procedures.html).

Answer 2

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

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

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

Answer 3

Я не писал хранимую процедуру почти 18 месяцев, потому что все мои вызовы SQL в основном выполняются с помощью LINQ с использованием ADO.NET Entity Framework.

Преимущества использования SPROC по сравнению, например, с использованием LINQ, заключаются в том, что простые изменения в SPROC не требуют перекомпиляции и публикации новой сборки.

SPROC не самые читаемые. Я имею в виду, что если у вас есть вызов: «GetData» в вашем коде, вы должны открыть SQL Server и посмотреть, что делает GetData, а не просто посмотреть на код LINQ, чтобы увидеть, что именно данные возвращаются.

Кроме того, никогда не позволяйте никому говорить вам, что SPROCS быстрее, потому что они скомпилированы или предварительно скомпилированы. Это миф Это не так.

Answer 4

Хранимые процедуры иногда становятся большими.
И их действительно сложно отлаживать.
Если у вас есть SP, содержащий сотни строк кода, трудно найти там ошибки.

Answer 5

Я предпочитаю использовать хранимые процедуры. Тем более, что некоторые из них очень сложны. Вы можете установить необязательные параметры, используя where (@PARAM IS NULL ИЛИ [FIELD] = @PARAM), чтобы помочь устранить эту проблему и создать динамические запросы. Мне также нравятся отладочные запросы в SQL. Я понимаю все остальные минусы.

Используйте то, что вам удобно, и что делает работу! Если вы хотите использовать все SP, сделайте это. Если вы хотите жестко их кодировать - делайте это ... но удачи.

Answer 6

Они очень хороши для большой обработки - иногда они быстрее, хотя и не всегда, в зависимости от структуры ваших данных и обработки. Без сомнения, для загрузки данных или изменения данных на основе пользовательского ввода SP являются предпочтительным маршрутом.

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

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

Answer 7

Я не использую SP для действительно простых запросов.Например, если я хочу показать пользователю все категории, используемые в нашем приложении, я просто напишу SELECT CategoryName FROM Categories вместо того, чтобы делать SP только для этого запроса из 4 слов.

Однако все, что требует ввода - это SP, независимо от того, насколько это просто.

Answer 8

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

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

Answer 9

Нет, правда.

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

Только случай IМожно подумать, что это будет особенно сложный запрос условия динамического поиска, который может иметь слишком много перестановок, чтобы создавать отдельные процедуры или операторы, и может быть проще генерировать на вашем клиентском языке, чем генерировать на TSQL и использовать EXEC / sp_executesql

Или, очевидно, вы бы не стали создавать хранимые процедуры для полностью произвольных запросов.