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

Хранимые процедуры выполняются на стороне сервера.

Это означает, что обработка больших объемов данных не требует передачи этих данных по сетевому соединению.

Кроме того, с помощью хранимых процедур вы можете создавать последовательную сложную бизнес-логику.

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

Вместо того, чтобы делать это с помощью триггеров (которые реализованы с использованием неэффективного подхода «запись за записью» во многих системах), вы можете передать табличную переменную или временную таблицу с входными данными и выполнить оператор SQL на основе набора внутри процедуры. Это будет намного эффективнее.

Я предпочитаю SP логике программирования в основном по двум причинам.

• Performance, anything what will reduce result set or can be more effectively done on the server, e.g.:
  • paging
  • фильтрация
  • порядок (по индексированным столбцам)
• Безопасность - если кто-то получил доступ приложения к базе данных и хочет стереть все ваши записи, необходимость выполнять Row_Delete для каждой из них вместо DELETE FROM Rows уже звучит хорошо.

Никогда, если вы не определите проблему с производительностью. (в основном мнение)

(сообщение в блоге Джеффа!) http://www.codinghorror.com/blog/2004/10/who-needs-stored-procedures-anyways.html

Если вы видите сохраненные процессы как оптимизации: http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize

Когда это уместно.

• сложная логика проверки/проверки данных
• избегать нескольких круговых поездок для выполнения одного действия в БД
• несколько клиентов
• все, что должно быть установлено на основе

Нельзя говорить «никогда» или «всегда».

Существует также случай, когда механизм базы данных переживет ваш клиентский код. Бьюсь об заклад, есть больше обновлений/рефакторинга DAL или ORM, чем обновления/рефакторинга механизма БД.

Наконец, почему я не могу инкапсулировать код в хранимую процедуру? Разве это не хорошо?

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

Здесь есть несколько точек зрения, и эти дебаты всегда вызывают сильные чувства с обеих сторон.

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

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

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

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