Хранимые процедуры и ORM

Какова цель хранимых процедур по сравнению с использованием ORM (nHibernate, EF и т.д.) Для обработки некоторых операций CRUD? Чтобы вызвать хранимую процедуру, мы просто передаем несколько параметров и с помощью ORM отправляем весь SQL-запрос, но это только вопрос производительности и безопасности или есть больше преимуществ?

Я спрашиваю об этом, потому что я никогда не использовал хранимые процедуры (я просто пишу все операторы SQL с помощью ORM и выполняю их), и клиент сказал мне, что мне придется работать с хранимыми процедурами в моем следующем проекте. Я пытаюсь понять, когда их использовать.

Ответ 1

Хранимые процедуры часто записываются на диалекте SQL (T-SQL для SQL Server, PL-SQL Oracle и т.д.). Это потому, что они добавляют дополнительные возможности SQL, чтобы сделать его более мощным. С другой стороны, у вас есть ORM, позвольте сказать, что NH генерирует SQL.

SQL-операторы, генерируемые ORM, не имеют одинаковой скорости или мощности для записи хранимых процедур T-SQL. Вот в чем заключается дилемма: Нужно ли мне быстрое приложение, привязанное к поставщику базы данных SQL, трудно поддерживать или мне нужно быть гибким, потому что мне нужно настроить таргетинг на несколько баз данных, и я предпочитаю сократить время разработки, написав запросы HQL, чем SQL из них?

Сохраненная процедура выполняется быстрее, чем операторы SQL, потому что они предварительно скомпилированы в Database Engine, с планами выполнения кэширования. Вы не можете сделать это в NH, но у вас есть другие альтернативы, например, с использованием уровня 1 или 2 кеша.

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

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

Ответ 2

В некоторых случаях существуют значительные преимущества в отношении производительности хранимых процедур. Часто запросы, созданные Linq и другими ORM, могут быть неэффективными, но все же достаточно хорошими для ваших целей. Некоторые RBDMS (такие как SQL Server) будут кэшировать планы выполнения хранимых процедур, сохраняя время запроса. Для более сложных запросов, которые вы часто используете, такая экономия в производительности может быть критической.

Однако для большинства обычных CRUD я обнаружил, что для удобства обслуживания обычно лучше использовать ORM, если он доступен, и если его операции удовлетворяют вашим потребностям. Entity Framework работает очень хорошо для меня в .NET-мире большую часть времени (в сочетании с Linq), и мне очень нравится Propel для PHP.

Ответ 3

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

Ответ 4

Я в основном придерживаюсь linq to sql как ORM, и я думаю, что он замечательный, но все еще есть место для хранимых процедур. В основном я использую, когда запрос, который я хочу запустить, очень сложный, со многими объединениями (особенно внешними объединениями, которые сосут Linq), много агрегации в подзапросах, возможно, рекурсивных CTE и других подобных сценариях.

В общем случае, в общем, нет необходимости.

Ответ 5

Поскольку le dorfier упоминает одну из основных причин, почему sprocs (и/или представления) следует использовать, это обеспечить уровень абстракции между базой данных и ее клиентами (веб-приложениями, отчетами, ETL и т.д.).

Этот "API БД" может упростить изменение/реорганизацию вашей базы данных, не обязательно влияя на клиентов.

Смотрите - Зачем использовать хранимые procs - для более глубокого обсуждения

Ответ 6

(Я испытываю желание сказать "только") причина, по которой вам следует использовать хранимые процедуры, - это если вам действительно нужна производительность.

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

Такие приложения становятся хрупкими, трудными для отладки и трудными для понимания. Позволяя бизнес-логике жить в хранимых процедурах, вы позволяете разработчикам SQL делать выбор дизайна, который им не следует делать, в инструменте, с которым гораздо сложнее работать, чем в ORM. Я видел хранимые процедуры, которые обрабатывают обработку платежей. Истинно основной материал. Материал, который становится настолько важным для приложения, что никто не осмеливается его трогать, и все потому, что какой-то парень с хорошими навыками SQL создал 5 лет назад базовый сценарий, который должен был сделать что-то гораздо меньшее. Он никогда не был перенесен в ORM и в итоге превратился в неуправляемого монстра, полного запутанной логики, которую никто больше не понимает. В конечном итоге разработчики вынуждены слепо доверять тому, что они делают.

Вы этого не хотите.

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

Конечно, будут случаи, когда ORM имеет ужасную производительность или просто не может что-то сделать. В этих случаях выполнение некоторых действий в сыром SQL может быть неизбежным. Но сведите это к минимуму, если можете. Как всегда, технический долг, как и финансовый долг, неплох, если вы знаете, когда его использовать и как им управлять.