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

Question

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

Answer 1

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

Answer 2

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

Существует множество преимуществ их использования, см. Здесь для справки: http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/

Редактировать: хотя статья за 2007 год, основные принципы в основном одинаковы

Answer 3

Этот вопрос часто задают, и здесь - хороший пост на эту тему.

Однако я лично сказал бы, что избегайте сложной логики в хранимых процедурах, которую трудно поддерживать позже, и это не так.лучшее место, чтобы положить его.ORM мапперы в настоящее время используются довольно широко, и некоторые из более крупных (Hibernate / NHIbernate, EF и т. Д.) Все производят оптомизированные запросы и имеют отличные стратегии кэширования.

Также избегайте системы с большим количеством хранимых процедур (I ').Я видел систему с более чем 4 тыс. сохраненных процедур и, поверьте, вы не хотите туда заходить).

Редактировать

Я должен был расширить свой ответ иСделайте это сейчас, однако хранимые процедуры имеют большое применение, потому что они выполняются на самом сервере и отлично подходят для обработки больших объемов данных, а не для выкупа их по сетевому соединению, и вам может потребоваться несколько обращений к базе данных.чтобы получить тот же результат, я склоняюсь к выборке в хранимой процедуре, большинство ORMS может выполнить sproc и вернуть сопоставленные результаты, и это добавляет к богатству решения orm.

Однако, если вы найдете всевы выполняете sprocs исключительно через ORM, тогда вам на самом деле не нужен orm.Таким образом, в наши дни его производительность производительности.Что касается больших наборов данных.Также, как правило, существует много дезинформированных мнений / привычек от разработчиков и администраторов баз данных, что может привести к воинственному положению вещей, когда людям говорят «весь код должен быть в sprocs» или «весь код должен быть сгенерированк слову "это глупое положение вещей.

Еще одна вещь, на которую я хотел бы обратить внимание: я видел sprocs со всевозможными ошибками в них, и, по нашей природе, разработчики программного обеспечения обычно не лучшие люди.писать sql так, как мы не склонны мыслить в стиле "set-like".Это не значит, что разработчики не могут писать отличный SQL-код, это просто не наша специализация.

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

Answer 4

Лучше всего использовать хранимые процедуры.

1. Разделение труда.
2. Многоразовый (можно тестировать напрямую из SQL)
3. Вы можете использовать одну процедуру для многих целей, это сократит ваше время, если в вашем программном обеспечении произойдут некоторые изменения.
4. Нет необходимости заменять какой-либо код в программе, особенно в DLL.