Каковы плюсы и минусы сохранения SQL в хранимых процессах по сравнению с кодом [закрыто]

Каковы преимущества / недостатки хранения SQL в исходном коде C # или в хранимых процессах? Я обсуждал это с другом в проекте с открытым исходным кодом, над которым мы работаем (C # ASP.NET Forum). В настоящее время большая часть доступа к базе данных осуществляется путем встроенного SQL в C # и обращения к БД SQL Server. Поэтому я пытаюсь определить, какой для этого конкретного проекта будет наилучшим.

Пока что у меня есть:

Преимущества для в коде:

  • Проще поддерживать - не нужно запускать SQL-скрипт для обновления запросов
  • Проще портировать на другую БД - без процов на порт

Преимущества для хранимых процедур:

  • Спектакль
  • Безопасность
18.08.2008 19:54:39
Вы также можете утверждать, что Stored Procs упрощает обслуживание - вам не нужно повторно развертывать все приложение, просто чтобы изменить один запрос.
Darren Gosbell 31.10.2008 03:32:18
@GvS: это дисфункция вашей компании, а не лучшая практика. Конечно, проще изменить вещи в 1 месте, чем в 1000. Администраторы баз данных просто вносят свой вклад в предотвращение кавалерийских изменений в системе, и это следует соблюдать.
Jeremy Holovacs 7.09.2011 14:27:28
30 ОТВЕТОВ
РЕШЕНИЕ

Я не фанат хранимых процедур

Хранимые процедуры более удобны в обслуживании, потому что: * Вам не нужно перекомпилировать свое приложение C # всякий раз, когда вы хотите изменить какой-либо SQL

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

  • В итоге вы снова используете код SQL.

Языки программирования, включая C #, имеют эту удивительную вещь, называемую функцией. Это означает, что вы можете вызывать один и тот же блок кода из нескольких мест! Удивительный! Затем вы можете поместить повторно используемый код SQL в один из них, или, если вы хотите получить действительно высокотехнологичный, вы можете использовать библиотеку, которая сделает это за вас. Я считаю, что они называются объектно-реляционными картографами, и в наши дни они довольно распространены.

Повторение кода - худшее, что вы можете сделать, когда пытаетесь создать поддерживаемое приложение!

Согласен, вот почему хранимые процессы - плохая вещь. Гораздо проще реорганизовать и разложить (разбить на более мелкие части) код на функции, чем SQL на ... блоки SQL?

У вас есть 4 веб-сервера и несколько приложений для Windows, которые используют один и тот же код SQL. Теперь вы поняли, что с кодом SQl есть небольшая проблема, поэтому вы предпочитаете ...... изменить процедуру в 1 месте или отправить код всем веб-серверы, переустановите все настольные приложения (может помочь clickonce) на всех окнах

Почему ваши приложения Windows подключаются напрямую к центральной базе данных? Это похоже на ОГРОМНУЮ дыру в безопасности и узкое место, поскольку исключает кеширование на стороне сервера. Разве они не должны подключаться через веб-сервис или аналогично вашим веб-серверам?

Итак, нажмите 1 новый sproc или 4 новых веб-сервера?

В этом случае это проще нажать одну новую sproc, но по моему опыту, 95% от «подтолкнули изменений» влияют на код , а не базы данных. Если вы отправляете 20 вещей на веб-серверы в этом месяце, а 1 - на базу данных, вы вряд ли сильно потеряете, если вместо этого отправите 21 вещь на веб-серверы и ноль на базу данных.

Проще пересмотреть код.

Можете ли вы объяснить, как? Я не понимаю этого. Особенно учитывая, что спроки, вероятно, не находятся в управлении исходным кодом, и поэтому не могут быть доступны через веб-браузеры SCM и так далее.

Больше минусов:

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

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

179
19.09.2013 15:28:31

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

Больше преимуществ для хранимых процедур:

  • Предотвратить обратный инжиниринг (если он создан с шифрованием, конечно)
  • Лучшая централизация доступа к базе данных
  • Возможность прозрачного изменения модели данных (без необходимости развертывания новых клиентов); особенно удобно, если несколько программ обращаются к одной модели данных
22
18.08.2008 19:57:57

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

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

Я не думаю, что поддерживать хранимые процедуры сложнее, вы не должны кодировать их непосредственно в базе данных, но сначала в отдельных файлах, затем вы можете просто запускать их в любой БД, которую вам нужно настроить.

13
18.08.2008 20:01:04
Если вы обнаружите, что принимаете базовые архитектурные решения, чтобы избежать перекомпиляции кода, то прежде чем что-либо делать, создайте процесс сборки, который не полностью отстой. Это не аргумент.
Michael Borgwardt 17.04.2009 14:25:46

Я предпочитаю хранить их в коде (используя ORM, а не inline или ad-hoc), поэтому они защищены системой контроля версий без необходимости сохранять файлы .sql.

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

6
18.08.2008 20:01:27

Это обсуждается в нескольких других темах здесь в настоящее время. Я являюсь последовательным сторонником хранимых процедур, хотя приводятся некоторые хорошие аргументы в пользу Linq для Sql.

Встраивание запросов в ваш код тесно связывает вас с вашей моделью данных. Хранимые процедуры являются хорошей формой контрактного программирования. Это означает, что администратор БД имеет право изменять модель данных и код в процедуре, если поддерживается контракт, представленный входами и выходами хранимой процедуры.

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

[Редактировать] Вот еще одно текущее обсуждение

99
23.05.2017 12:10:10

Преимущества для в коде:

  • Проще поддерживать - не нужно запускать SQL-скрипт для обновления запросов
  • Проще портировать на другую БД - без процов на порт

На самом деле, я думаю, что у вас есть это задом наперед. ИМХО, SQL в коде - боль в поддержке, потому что:

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

Хранимые Procs воспринимаются как методы, которые вы вызываете из объекта базы данных - их гораздо проще использовать повторно, есть только одно место для редактирования, и если вы меняете поставщиков БД, изменения происходят в ваших Stored Procs, а не в вашем коде ,

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

44
17.04.2009 14:10:18

Одно из предложений от сеансов Microsoft TechEd по безопасности, которые я посетил, чтобы сделать все вызовы через хранимые процедуры и запретить доступ непосредственно к таблицам. Этот подход был объявлен как обеспечение дополнительной безопасности. Я не уверен, стоит ли это только ради безопасности, но если вы уже используете хранимые процедуры, это не повредит.

4
18.08.2008 20:10:20
Безопасность данных важна, когда вы имеете дело с личной информацией или финансовой информацией, особенно. Большая часть мошенничества совершается инсайдерами. Вы не хотите предоставлять им доступ, необходимый для обхода внутреннего контроля.
HLGEM 28.09.2008 19:00:03

Определенно легче поддерживать, если вы поместите его в хранимую процедуру. Если существует сложная логика, которая потенциально может измениться в будущем, то, безусловно, было бы неплохо поместить ее в базу данных, когда подключено несколько клиентов. Например, я сейчас работаю над приложением, которое имеет веб-интерфейс для конечного пользователя и приложение для рабочего стола администратора, оба из которых совместно используют базу данных (очевидно), и я стараюсь сохранить как можно больше логики в базе данных. Это прекрасный пример принципа СУХОЙ .

4
18.08.2008 20:15:39

Подумай об этом так

У вас есть 4 веб-сервера и несколько приложений для Windows, которые используют один и тот же код SQL. Теперь вы поняли, что с кодом SQl есть небольшая проблема, поэтому вы предпочитаете ...... изменить процедуру в 1 месте или отправить код всем веб-серверы, переустановите все настольные приложения (может помочь clickonce) на всех окнах

Я предпочитаю хранимые процы

Кроме того, проще выполнить тестирование производительности с помощью процесса, поместив его в анализатор запросов, установив статистику io / time, включив showplan_text и вуаля.

нет необходимости запускать профилировщик, чтобы увидеть, что именно называется

только мои 2 цента

7
18.08.2008 20:16:14

Вы перечисляете 2 pro-точки для sprocs:

Производительность - не совсем. В Sql 2000 или выше оптимизация плана запросов довольно хороша и кэшируется. Я уверен, что Oracle и т. Д. Делают подобные вещи. Я не думаю, что есть повод для sprocs для производительности больше.

Безопасность? Почему спроки могут быть более безопасными? Если у вас в любом случае нет достаточно незащищенной базы данных, весь доступ будет из ваших администраторов баз данных или через ваше приложение. Всегда параметризуйте все запросы - никогда не вставляйте что-либо из пользовательского ввода, и все будет в порядке.

Это лучшая практика для производительности в любом случае.

Linq - это, безусловно, путь, которым я бы сейчас занялся новым проектом. Смотрите этот похожий пост .

8
23.05.2017 12:17:54
Специальные планы выполнения SQL используются повторно только при определенных обстоятельствах: tinyurl.com/6x5lmd [SO ответ с подтверждением кода] Официально LINQ to SQL устарел : tinyurl.com/6298nd [запись в блоге]
HTTP 410 9.11.2008 11:34:48
Procs - безусловно самый безопасный путь. Они ограничивают пользователя только от выполнения действий в процессах. Они не могут напрямую перейти к таблице или представлению, к которому у них есть доступ для записи, и что-то изменить. Процедуры необходимы для предотвращения вреда от внутренних угроз.
HLGEM 26.08.2011 14:43:18

Я падаю на стороне кода . Мы создаем слой доступа к данным, который используется всеми приложениями (как веб-, так и клиентскими), поэтому с этой точки зрения он СУХОЙ. Это упрощает развертывание базы данных, потому что мы просто должны убедиться в правильности схемы таблицы. Это упрощает обслуживание кода, потому что нам не нужно смотреть на исходный код и базу данных.

У меня нет особых проблем с тесной связью с моделью данных, потому что я не вижу, где можно реально сломать эту связь. Приложение и его данные неразрывно связаны.

16
18.08.2008 20:29:35

Преимущества для хранимых процедур :

Проще пересмотреть код.

Менее спаренный, поэтому легче тестируется.

Более легко настраивается.

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

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

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

Недостатки:

Сложнее управлять разработчикам: контроль версий скриптов: есть ли у каждого своя база данных, интегрирована ли система контроля версий с базой данных и IDE?

13
7.02.2014 09:21:40
Да, вы можете иметь контроль версий в хранимых процедурах и базе данных в проекте базы данных Visual Studio 2012 и TFS.
hajirazin 27.06.2013 13:18:07

Хранимые процедуры более удобны в обслуживании, потому что:

  • Вам не нужно перекомпилировать ваше приложение на C # всякий раз, когда вы хотите изменить SQL
  • В итоге вы снова используете код SQL.

Повторение кода - худшее, что вы можете сделать, когда пытаетесь создать поддерживаемое приложение!

Что происходит, когда вы обнаружите логическую ошибку, которую необходимо исправить в нескольких местах? Вы более склонны забыть изменить последнее место, куда вы копировали и вставляли свой код.

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

Проще портировать на другую БД - без процов на порт

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

2
18.08.2008 20:44:20
Просто примечание: «Проще переносить на другую БД - никаких процедур для переноса» относится к переносу на другую СУБД , а не просто к другой установке. Знаете, есть альтернативы ;-).
sleske 8.12.2009 10:47:58

@Keith

Безопасность? Почему спроки могут быть более безопасными?

Хранимые процедуры обеспечивают защиту от атак SQL-инъекций .

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

1
18.08.2008 20:51:16

@Keith

Безопасность? Почему спроки могут быть более безопасными?

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

(Конечно, выполнение sprocs может дать им все необходимые данные, но это будет зависеть от доступных sprocs. Предоставление им доступа к таблицам дает им доступ ко всему.)

8
18.08.2008 21:12:39
@Joe Philllips, представления не дают вам лучшей или даже равной безопасности для проков, и они НЕ будут полезны для предотвращения мошенничества или внутреннего вреда. Когда вы используете процы, модель безопасности заключается в том, что пользователи получают доступ только к процессу, а не к таблицам или представлениям, и поэтому они не могут делать ничего, кроме того, что делает процесс. Если у вас есть финансовые данные и вы не используете процы, ваша система находится в опасности.
HLGEM 26.08.2011 14:41:12

@Terrapin - sprocs так же уязвимы для инъекционных атак. Как я сказал:

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

Это касается sprocs и динамического Sql.

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


@ Да, да, вы правы, sprocs позволяет вам контролировать пользователей приложений, чтобы они могли выполнять только sproc, а не основное действие.

Мой вопрос был бы: если весь доступ к нему через ваше приложение, используя соединения и пользователей с ограниченными правами на обновление / вставку и т. Д., Добавляет ли этот дополнительный уровень безопасности или дополнительного администрирования?

Мое мнение очень последнее. Если они скомпрометировали ваше приложение до такой степени, что они могут переписать его, у них есть множество других атак, которые они могут использовать.

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

2
18.08.2008 21:32:57
Вам нужно сражаться не только вне атак. Вы не можете разрешить прямой доступ к таблицам пользователям, которые могут затем изменить данные для совершения мошенничества.
HLGEM 28.09.2008 18:56:11
Как политика, хранимым процессам нельзя разрешать использовать динамический SQL, почти всегда есть нединамическое решение, если вы ищете его.
HLGEM 28.09.2008 18:57:01
Внедрение SQL не так эффективно против sprocs с динамически встроенным кодом, потому что динамический код выполняется с разрешением вызывающего, а не с владельцем (в отличие от статического кода). Это верно для SQL Server - не уверен насчет Oracle.
HTTP 410 9.11.2008 11:38:49

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

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

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

6
18.08.2008 22:26:41
Когда несколько приложений обращаются к одной и той же базе данных, а базы данных зависят от импорта и другого прямого доступа (обновите все цены на 10%), логика должна быть в базе данных, иначе вы потеряете целостность базы данных.
HLGEM 28.09.2008 18:54:59
В случае нескольких приложений размещение логики в библиотеке, которая используется всеми приложениями, позволяет поддерживать целостность при сохранении логики на языке приложения. Для импорта / прямого доступа обычно ситуационный вопрос о том, следует ли применять правила, применимые к приложениям, или нет.
Dave Sherohman 23.10.2008 14:07:15
несколько приложений не должны вносить одинаковые изменения в базу данных. должен быть один компонент приложения, который имеет дело с одним типом изменений. Тогда это приложение должно предоставлять сервис, если другие заинтересованы. Несколько приложений, изменяющих одну и ту же базу данных / таблицу по своему усмотрению, являются причиной того, что система приложений и база данных становятся неуправляемыми.
Jiho Han 27.02.2010 03:57:16
«должен быть один компонент приложения, который имеет дело с изменениями одного типа» - этот компонент может быть хранимой процедурой, скажем, в PL / SQL.
RussellH 13.10.2010 20:45:52

Атаки SQL-инъекций находятся на подъеме. Для кого-то очень легко найти этот код и проводить инъекционные атаки на вашем сайте. Вы всегда должны всегда параметризировать ваши запросы. Лучше никогда не запускать exec (@x) для динамического SQL-запроса. Просто не очень хорошая идея использовать встроенный SQL, IMO.

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

1
19.08.2008 05:44:14
Non-нелогичным. Встроенные и динамические запросы можно параметризовать так же легко, как и хранимые процедуры.
Dave Sherohman 23.10.2008 14:10:15

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

1
19.08.2008 19:25:17
Чтобы проголосовать, просто используйте треугольную стрелку слева от понравившегося ответа;)
Constantin 28.09.2008 18:21:41

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

Большой поклонник Transact SQL, настройка больших запросов оказалась для меня очень полезной. За 6 лет не написал ни одного встроенного SQL!

9
29.08.2008 21:27:58
Я просто не могу понять другую точку зрения, используя запросы в коде, просто не могу понять ...
Chaki_Black 26.11.2013 21:13:55

В некоторых случаях динамически создаваемый sql-код может иметь более высокую производительность, чем хранимый процесс. Если вы создали хранимый процесс (скажем, sp_customersearch), который становится чрезвычайно сложным с десятками параметров, потому что он должен быть очень гибким, вы, вероятно, можете сгенерировать гораздо более простой оператор SQL в коде во время выполнения.

Можно утверждать, что это просто переносит некоторую обработку с SQL на веб-сервер, но в целом это было бы хорошо.

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

11
5.09.2008 16:01:03
Не уверен, почему этот ответ был отклонен .. это правда, что меньший запрос может работать лучше. Это даже прокомментировано командой SQL Server.
Brannon 25.09.2008 07:53:12

Что-то, что я не видел, упомянуто до сих пор: люди, которые знают базу данных лучше всего, не всегда люди, которые пишут код приложения. Хранимые процедуры дают возможность пользователям баз данных взаимодействовать с программистами, которые на самом деле не хотят много изучать SQL. Большие - и особенно унаследованные - базы данных - не самая простая вещь для полного понимания, поэтому программисты могут предпочесть простой интерфейс, который дает им то, что им нужно: позвольте администраторам баз данных выяснить, как объединить 17 таблиц, чтобы это произошло.

Тем не менее, языки, используемые для написания хранимых процедур (PL / SQL является пресловутым примером), довольно жестоки. Как правило, они не предлагают никаких изысков, которые вы бы увидели на популярных популярных императивах, ООП или функциональных языках. Подумай, Кобол.

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

2
5.09.2008 16:17:30
«Языки, используемые для написания хранимых процедур (PL / SQL является пресловутым примером), довольно жестоки [и] не предлагают никаких тонкостей, которые вы бы видели в современных популярных языках». Вам необходимо перечитать документы по PL / SQL ( download.oracle.com/docs/cd/B28359_01/appdev.111/b28370/toc.htm ). PL / SQL имеет инкапсуляцию с использованием пакетов, ООП через типы объектов, обработку исключений, динамическое выполнение кода, отладчики, профилировщики и т. Д., А также сотни стандартных пакетов / библиотек, предоставляемых Oracle, для выполнения любых задач, от HTTP-вызовов до шифрования и регулярных выражений. , PL / SQL имеет много тонкостей.
ObiWanKenobi 5.08.2009 22:51:01

Когда дело доходит до безопасности, хранимые процедуры намного более безопасны. Некоторые утверждают, что все доступ будет через приложение в любом случае. Многие люди забывают, что большинство нарушений безопасности происходят изнутри компании. Подумайте, сколько разработчиков знают «скрытое» имя пользователя и пароль для вашего приложения?

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

По моему опыту, абстракция модели данных с помощью хранимых процедур также значительно повышает удобство сопровождения. Как человек, которому в прошлом приходилось обслуживать много баз данных, это такое облегчение, когда он сталкивается с необходимостью изменения модели, чтобы иметь возможность просто изменить одну или две хранимые процедуры и сделать это изменение полностью прозрачным для ВСЕХ внешних приложений. Много раз ваше приложение не единственное, которое указывает на базу данных - существуют другие приложения, решения для составления отчетов и т. Д., Поэтому отслеживание всех этих затронутых точек может быть проблемой с открытым доступом к таблицам.

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

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

6
17.09.2008 14:40:22
При изменении модели, как правило, код также должен изменяться независимо от того, используется ли sprocs или динамический sql. И как только вы создаете таблицы / схемы, как часто вы меняете только таблицу / схему? Не часто. Обычно изменения происходят из бизнеса, когда им нужно добавить еще один столбец или другую таблицу, и в этом случае я сомневаюсь, что вы можете обойтись без изменения кода.
Jiho Han 27.02.2010 04:01:36

ПРОТИВ

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

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

ПРОФИ

  1. Производительность того, чего она может стоить (избегает анализа запросов драйвером БД / воссозданием плана и т. Д.)
  2. Манипулирование данными не встроено в код C / C ++ / C #, что означает, что у меня есть менее низкоуровневый код для просмотра. SQL менее многословен и его легче просматривать, если он указан отдельно.
  3. Благодаря разделению люди могут гораздо проще находить и повторно использовать код SQL.
  4. При изменении схемы проще что-то менять - нужно просто дать тот же вывод коду, и он будет работать нормально
  5. Проще портировать на другую базу данных.
  6. Я могу перечислить индивидуальные разрешения для моих хранимых процедур и контролировать доступ на этом уровне.
  7. Я могу профилировать свой запрос данных / постоянный код отдельно от моего кода преобразования данных.
  8. Я могу реализовать изменяемые условия в моей хранимой процедуре, и это будет легко настроить на сайте клиента.
  9. Становится проще использовать некоторые автоматизированные инструменты для преобразования моей схемы и операторов вместе, а не тогда, когда они встроены в мой код, где мне пришлось бы выследить их.
  10. Обеспечение соответствия рекомендациям по доступу к данным становится проще, когда у вас есть весь код доступа к данным в одном файле - я могу проверить запросы, которые обращаются к неработающей таблице или к тем, которые используют более высокий уровень сериализации, или выбрать * в коде и т. Д. ,
  11. Становится легче находить изменения схемы / изменения логики манипулирования данными, когда все они перечислены в одном файле.
  12. Поиск и замена правок в SQL становится проще, когда они находятся в одном месте, например, операторы изменения / добавления изоляции транзакции для всех хранимых процедур.
  13. Я и парень из DBA находим, что иметь отдельный файл SQL проще / удобнее, когда администратор базы данных должен просмотреть мои материалы по SQL.
  14. Наконец, вам не нужно беспокоиться об атаках SQL-инъекций, потому что некоторые ленивые члены вашей команды не использовали параметризованные запросы при использовании встроенных sqls.
33
2.03.2010 19:24:01

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

0
25.09.2008 08:00:41
Что такого сложного в том, чтобы нажать кнопку «Создать скрипт» и зафиксировать ее в репозитории?
Constantin 28.09.2008 18:24:42
У нас нет проблем с сохранением всех сохраненных процедур в системе контроля версий. Конечно, наш dbas удаляет все, чего нет в нем.
HLGEM 28.09.2008 18:51:55

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

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

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

Использование богатых библиотек генерации SQL, таких как LINQ, Rails ActiveRecord или Hibernate / NHibernate, ускоряет разработку. Вставка хранимых процедур в микс замедляет его.

1
27.09.2008 02:49:34
Я должен категорически не согласиться с этим утверждением. Весь код не является кодом приложения, хранимые процедуры более безопасны, если вы не разрешаете динамический sql (что не следует делать), потому что тогда вы можете установить безопасность на уровне sp, а не на уровне таблицы. Это предотвращение мошенничества.
HLGEM 28.09.2008 18:51:01

Меньшие журналы

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

3
28.09.2008 18:32:42

Я твердо на стороне хранимых процедур, предполагая, что вы не обманываете и не используете динамический SQL в хранимых процессах. Во-первых, использование хранимых процедур позволяет dba устанавливать разрешения на уровне хранимых процедур, а не на уровне таблицы. Это важно не только для борьбы с атаками SQL-инъекций, но и для предотвращения прямого доступа инсайдеров к базе данных и изменения вещей. Это способ предотвратить мошенничество. Никакая база данных, которая содержит личную информацию (номера SSN, номера кредитных карт и т. Д.) Или которая в любом случае создает финансовые транзакции, никогда не должна быть доступна, кроме как через строгие процедуры. Если вы используете любой другой метод, вы оставляете свою базу данных широко открытой для частных лиц в компании, чтобы создавать фальшивые финансовые транзакции или похищать данные, которые можно использовать для кражи личных данных.

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

4
28.09.2008 18:47:49

Я предпочитаю использовать O / R Mapper, такой как LLBLGen Pro .

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

На самом деле, возможность работать со строго типизированными объектами является достаточной причиной для использования O / R Mapper.

1
2.10.2008 21:12:19

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

В нашем DAL, если у нас очень сложные операторы SQL, мы обычно включаем их в качестве файлов ресурсов и обновляем их по мере необходимости (это может быть также отдельная сборка с заменой на дБ и т. Д.).

Это сохраняет наш код и наши вызовы sql в одном контроле версий, не забывая запускать некоторые внешние приложения для обновления.

2
7.07.2010 14:56:13
Что делать, когда вы «забыли» повторить изменения в таблицах?
craigmoliver 17.08.2011 03:38:55
Процесс может решить проблемы развертывания.
Tom Anderson 17.08.2011 21:52:10