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

Ответ 1

Я не являюсь поклонником хранимых процедур

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

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

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

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

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

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

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

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

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

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

Более простой обзор кода.

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

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

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

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

Ответ 2

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

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

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

[Изменить] Вот еще текущее обсуждение

Ответ 3

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

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

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

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

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

Ответ 4

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

• Легче поддерживать - не нужно запускать SQL script для обновления запросов
• Легче переносить на другой БД - нет проков в порт

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

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

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

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

Ответ 5

CON

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

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

ПРОФИ

• Производительность для того, что она может стоить (избегает анализа синтаксиса с помощью драйвера DB/планирования и т.д.)
• Обработка данных не встроена в код C/С++/С#, что означает, что у меня есть код менее низкого уровня для просмотра. SQL менее подробен и проще просматривать, если он указан отдельно.
• Из-за разделения люди могут намного легче найти и повторно использовать код SQL.
• Легче изменить вещи при изменении схемы - вам просто нужно дать тот же результат для кода, и он будет работать просто отлично
• Легче переносить в другую базу данных.
• Я могу перечислять индивидуальные разрешения для моих хранимых процедур и контролировать доступ на этом уровне.
• Я могу профилировать свой код запроса/сохранности данных отдельно от кода преобразования данных.
• Я могу реализовать изменчивые условия в своей хранимой процедуре, и ее было бы легко настроить на сайте клиента.
• Легче использовать некоторые автоматизированные инструменты для преобразования моих схем и операторов вместе, а не когда они встроены в мой код, где мне нужно будет их выслеживать.
• Обеспечение наилучшей практики для доступа к данным проще, когда у вас есть весь код доступа к данным внутри одного файла - я могу проверить запросы, которые обращаются к нерабочей таблице или к которой используется более высокий уровень сериализации или выбрать * в коде и т.д.
• Легче найти изменения схемы/изменения логики данных, когда все они перечислены в одном файле.
• Легче выполнять поиск и замену изменений на SQL, когда они находятся в одном месте, например. изменить/добавить операторы изоляции транзакций для всех сохраненных процедур.
• Я и парень DBA считают, что наличие отдельного SQL файла проще и удобнее, когда администратор баз данных должен пересмотреть мои вещи SQL.
• Наконец, вам не нужно беспокоиться об атаках SQL-инъекций, потому что какой-то ленивый член вашей команды не использовал параметризованные запросы при использовании встроенных SQL-запросов.

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

Сохраненные процедуры.

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

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

Ответ 9

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

Более простой обзор кода.

Менее связаны, поэтому более легко тестируются.

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

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

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

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

Недостатки:

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

Ответ 10

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

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

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

Ответ 11

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

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

Ответ 12

Вы указываете 2 про-точки для sprocs:

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

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

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

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

Ответ 13

@Keith

Безопасность? Почему sprocs будет более безопасным?

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

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

Ответ 14

Подумайте об этом таким образом

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

Я предпочитаю сохраненные procs

Также проще выполнить тестирование производительности против proc, поместить его в анализатор запросов установить статистику io/time on set showplan_text on и voila

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

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

Ответ 15

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

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

Ответ 16

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

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

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

Ответ 17

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

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

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

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

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

Ответ 18

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

Ответ 19

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

Ответ 20

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

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

Ответ 21

Мы используем хранимые процедуры с Oracle DB, где я сейчас работаю. Мы также используем Subversion. Все хранимые процедуры создаются как файлы .pkb и .pks и сохраняются в Subversion. Я уже делал он-лайн SQL, и это боль! Я предпочитаю, как мы это делаем. Создание и тестирование новых хранимых процедур намного проще, чем выполнение этого кода.

Theresa

Ответ 22

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

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

Ответ 23

Я не большой поклонник хранимых процедур, но я использую их в одном условии:

Когда запрос довольно огромен, лучше сохранить его в базе данных как хранимую процедуру, а не отправлять ее из кода. Таким образом, вместо отправки огромных массивов строковых символов с сервера приложений в базу данных будет отправлена ​​только команда "EXEC SPNAME".

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

Но человек, им так страшно управлять. Я избегаю их, насколько могу.

Ответ 24

SQL-хранимый proc не увеличивает производительность запроса

Ответ 25

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

• Ваша реализация кода и SQL становятся независимыми друг от друга.
• Код легче читать.
• Пишите один раз много раз.
• Изменить один раз
• Не нужно указывать внутреннюю информацию программисту о базе данных. и т.д. и т.д.

Ответ 26

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

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

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

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

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

Легче переносить на другой БД - нет procs для порта

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

Ответ 27

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

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

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

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

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

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

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

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

Ответ 28

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

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

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

Ответ 29

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

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

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

Ответ 30

Я вообще пишу OO-код. Я подозреваю, что большинство из вас, вероятно, тоже. В этом контексте мне кажется очевидным, что вся бизнес-логика, включая SQL-запросы, принадлежит к определениям классов. Разделение логики таким образом, что ее часть находится в объектной модели, а часть находится в базе данных, не лучше, чем перенос бизнес-логики в пользовательский интерфейс.

В более ранних ответах сказано много о преимуществах безопасности хранимых процессов. Они делятся на две широкие категории:

1) Ограничение прямого доступа к данным. Это определенно важно в некоторых случаях, и когда вы сталкиваетесь с одним, тогда сохраненные procs - это в значительной степени ваш единственный вариант. Однако, по моему опыту, такие случаи являются скорее исключением, чем правилом.

2) SQL-инъекции/параметризованные запросы. Это возражение - красная селедка. Встроенный SQL - даже динамически сгенерированный встроенный SQL - может быть так же полностью параметризован, как и любой сохраненный процесс, и его можно сделать так же легко на любом современном языке, достойном его соли. Здесь нет никакого преимущества. ( "Ленивые разработчики могут не беспокоиться об использовании параметров" ) не является допустимым возражением. Если у вас есть разработчики в вашей команде, которые предпочитают просто конкатенацию пользовательских данных в свой SQL вместо использования параметров, сначала попробуйте их обучить, затем вы их запускаете если это не сработает, как и с разработчиками, у которых есть какая-то другая плохая, явно вредная привычка.)