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

Ошибка: функция round (double precision, integer) не существует

Решение: вам нужно добавить тип добавления, тогда он будет работать

Пример: round(extract(second from job_end_time_t)::integer,0)

274
задан 3 revs, 3 users 100% 27 October 2008 в 14:46
поделиться

39 ответов

Я не поклонник хранимых процедур

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

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

  • , Вы заканчиваете тем, что снова использовали код SQL.

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

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

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

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

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

Так, продвиньте 1 новый sproc или 4 новых веб-сервера?

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

более легко код рассматривается.

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

[еще 117] недостатки:

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

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

179
ответ дан 4 revs, 2 users 98% 4 November 2019 в 11:46
поделиться

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

Однако языки раньше писали, что хранимые процедуры (МН / SQL известный пример) являются довольно жестокими. Они обычно не предлагают ни одной из тонкостей, которые Вы видели бы в сегодняшнем популярном императиве, ООП или функциональных языках. Думайте КОБОЛ.

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

2
ответ дан yukondude 4 November 2019 в 11:46
поделиться

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

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

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

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

2
ответ дан Dave Sherohman 4 November 2019 в 11:46
поделиться

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

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

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

2
ответ дан 2 revs, 2 users 89% 4 November 2019 в 11:46
поделиться

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

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

, Который идет для sprocs и динамического Sql.

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

<час>

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

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

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

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

2
ответ дан Keith 4 November 2019 в 11:46
поделиться

Хранимые процедуры [еще 111] удобный в сопровождении потому что:

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

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

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

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

Легче к порту к другому DB - никакой procs к порту

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

2
ответ дан Seibar 4 November 2019 в 11:46
поделиться

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

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

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

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

99
ответ дан 2 revs 4 November 2019 в 11:46
поделиться

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

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

(Pseudocode)

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

Так в конце у Вас есть свой средний уровень, работающий на этих очень прохладных 4 кластерах Сервера каждый из них оборудованный 16 центральными процессорами, и это на самом деле не сделает ничего вообще! Какие отходы!

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

47
ответ дан 2 revs, 2 users 94% 4 November 2019 в 11:46
поделиться

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

  • Легче поддержать - не должны выполнять сценарий SQL к запросам на обновление
  • Легче к порту к другому DB - никакой procs к порту

На самом деле, я думаю, что у Вас есть это назад. По моему скромному мнению, SQL в коде является болью для поддержания потому что:

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

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

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

44
ответ дан 3 revs, 2 users 91% 4 November 2019 в 11:46
поделиться

ДОВОД "ПРОТИВ"

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

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

ПРОФЕССИОНАЛЫ

  1. Производительность для того, что это может стоить (избегает анализа запроса драйвером DB / воссоздание плана и т.д.)
  2. Манипулирование данными не встраивается в код C/C ++/C#, что означает, что у меня есть меньше низкоуровневого кода для просмотра. SQL является менее подробным и легче просмотреть, когда перечислено отдельно.
  3. из-за разделительных людей в состоянии найти и снова использовать намного легче код SQL.
  4. Ее более легкое для изменения вещей, когда схема изменяется - просто необходимо дать тот же вывод коду, и это будет работать просто великолепно
  5. Легче к порту к различной базе данных.
  6. я могу перечислить отдельные полномочия на своих хранимых процедурах и управлять доступом на том уровне также.
  7. я могу представить свой запрос данных / код персистентности, отдельный от моего кода преобразования данных.
  8. я могу реализовать изменяемые условия в своей хранимой процедуре, и было бы легко настроить на сайте для клиентов.
  9. становится легче использовать некоторые автоматизированные инструменты для преобразования моей схемы и операторов вместе скорее чем, когда это встраивается в моем коде, где я должен был бы выследить их.
  10. Удостоверяющиеся лучшие практики для доступа к данным легче, когда у Вас есть весь свой код доступа к данным в единственном файле - я могу проверить на запросы, что получают доступ не производительная таблица или что, который использует более высокий уровень сериализации или выбирает * в коде и т.д.
  11. , становится легче найти изменения схемы / изменения логики манипулирования данными, когда все это перечислено в одном файле.
  12. становится легче сделать поиск и редактирования замены на SQL, когда они находятся в том же месте, например, изменение / добавляют, что операторы изоляции транзакции для всех сохранили procs.
  13. я и парень DBA находим, что наличие отдельного файла SQL легче / удобный, когда DBA должен рассмотреть мой материал SQL.
  14. Наконец Вы не должны волноваться об атаках с использованием кода на SQL, потому что некоторый ленивый член Вашей команды не использовал параметризованные запросы, когда использование встроило sqls.
33
ответ дан 4 revs, 2 users 82% 4 November 2019 в 11:46
поделиться

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

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

  • Предотвращают инженерный анализ (если создано С Шифрованием, конечно)
  • Лучшая централизация доступа к базе данных
  • Способность изменить модель данных прозрачно (не имея необходимость развертывать новые клиенты); особенно удобный, если несколько программ получают доступ к той же модели данных
22
ответ дан Stu 4 November 2019 в 11:46
поделиться

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

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

16
ответ дан Rick 4 November 2019 в 11:46
поделиться

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

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

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

13
ответ дан mbillard 4 November 2019 в 11:46
поделиться

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

более легко код рассматривается.

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

более легко настроенный.

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

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

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

Недостатки:

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

13
ответ дан 2 revs, 2 users 94% 4 November 2019 в 11:46
поделиться

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

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

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

11
ответ дан Joel Hendrickson 4 November 2019 в 11:46
поделиться

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

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

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

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

Linq является определенно путем, которым я продолжил бы на новый проект прямо сейчас. Посмотрите этот подобное сообщение .

8
ответ дан 2 revs 4 November 2019 в 11:46
поделиться

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

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

9
ответ дан Natron 4 November 2019 в 11:46
поделиться

Думайте о нем этот путь

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

, я предпочитаю сохраненный procs

, также легче сделать тестирование производительности против proc, поместить его в запрос статистика набора анализатора io/time на наборе showplan_text на и вуаля

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

просто мои 2 цента

7
ответ дан SQLMenace 4 November 2019 в 11:46
поделиться

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

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

6
ответ дан John Sheehan 4 November 2019 в 11:46
поделиться

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

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

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

6
ответ дан 2 revsSanti 4 November 2019 в 11:46
поделиться

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

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

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

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

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

6
ответ дан Tom H 4 November 2019 в 11:46
поделиться

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

4
ответ дан Eugene Katz 4 November 2019 в 11:46
поделиться

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

4
ответ дан Andrew G. Johnson 4 November 2019 в 11:46
поделиться

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

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

4
ответ дан HLGEM 4 November 2019 в 11:46
поделиться

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

Theresa

4
ответ дан Theresa 4 November 2019 в 11:46
поделиться

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

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

3
ответ дан Constantin 4 November 2019 в 11:46
поделиться

безопасность @Keith

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

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

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

8
ответ дан Guy 4 November 2019 в 11:46
поделиться

безопасность @Keith

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

Хранимые процедуры предлагают свойственную защиту от Внедрение SQL нападения.

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

1
ответ дан Seibar 4 November 2019 в 11:46
поделиться

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

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

1
ответ дан MaseBase 4 November 2019 в 11:46
поделиться

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

1
ответ дан Preston 4 November 2019 в 11:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: