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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

• Производительность, что угодно, что уменьшит набор результатов или может быть более эффективно выполнено на сервере, например:
  • пейджинг
  • фильтрации
  • порядок (по индексированным столбцам)
• Безопасность - если кто-то получил доступ приложения к базе данных и хочет стереть все ваши записи, необходимо выполнить Row_Delete для каждого из них вместо DELETE FROM Rows, уже звучит хорошо.

Answer 3

При необходимости.

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

Вы не можете сказать «никогда» или «всегда».

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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

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

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