Что за и против являются к удержанию 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
поделиться

41 ответ

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

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

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

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

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

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

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

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

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

Мой голос за хранимые процедуры; как уровень абстракции близко к данным, эффективным с наборами, допускающими повторное использование многими "клиентами" (клиентские языки). Язык T-SQL немного примитивен (и я предполагаю, что это - то, что большинство парней C# здесь в ТАК было представлено), но МН Oracle / SQL на одном уровне с любым современным языком программирования.

Что касается управления версиями, просто помещает код хранимой процедуры в текстовые файлы при управлении версиями, затем выполняет сценарии для создания procs в базе данных.

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

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

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

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

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

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

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

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

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

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

3
ответ дан 23 November 2019 в 02:11
поделиться

Плюсы к хранимым процедурам 1). Повышенная безопасность, поскольку SQL в хранимой процедуре является статическим по своей природе (в основном). Это защитит от внедрения SQL. 2). Повторное использование. Если существует необходимость возвращать одни и те же данные для нескольких приложений / компонентов, это может быть лучшим выбором вместо повторения операторов SQL. 3). Сокращает количество вызовов между клиентом и сервером базы данных.

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

0
ответ дан 23 November 2019 в 02:11
поделиться

Твердо придерживается принципа «Хранимые процессы не подходят для использования CRUD / бизнес-логики». Я понимаю необходимость создания отчетов, импорта данных и т. Д.

Напишите здесь ...

0
ответ дан 23 November 2019 в 02:11
поделиться

Для Microsoft SQL Server по возможности следует использовать хранимые процедуры, чтобы помочь с кэшированием и повторным использованием плана выполнения. Почему вы хотите оптимизировать повторное использование плана? Поскольку создание планов выполнения обходится довольно дорого.

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

SELECT MyColumn FROM MyTable WHERE id = @id
select MyColumn from MyTable WHERE id = @id
SELECT MyColumn  FROM MyTable WHERE id = @id
SELECT MyColumn FROM MyTable WHERE id = @id -- "some comment"
SELECT MyColumn FROM MyTable WHERE id = @id -- "some other comment"

Вдобавок к этому,

-1
ответ дан 23 November 2019 в 02:11
поделиться

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

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

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

0
ответ дан 23 November 2019 в 02:11
поделиться

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

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

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

Запуск ad-hoc Запросы неудобны с хранимыми процедурами - это проще сделать с динамическим sql (или ORM), что может быть самым большим недостатком использования хранимых процедур для меня.

С другой стороны, хранимые процедуры удобны в ситуациях, когда вы вносите изменения, но не требует повторного развертывания кода приложения. Это также позволяет вам формировать ваши данные перед их отправкой по сети, где sql в коде, возможно, придется делать несколько вызовов для извлечения, чем формировать их (хотя теперь есть способы запускать несколько операторов sql и возвращать несколько наборов результатов за один вызов ", как в MARS в ADO.NET), что, вероятно, приведет к тому, что через вашу сеть будет передаваться больше данных.

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

0
ответ дан 23 November 2019 в 02:11
поделиться
Другие вопросы по тегам:

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