Является ли это действительным преимуществом использования встроенного SQL над хранимыми процедурами?

Question

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

Поскольку с каждой поездкой на сервер базы данных связаны накладные расходы, я бы предположил, что ВОЗМОЖНАЯ причина для размещения вашего SQL в SP вместо встроенного кода заключается в том, что вы более изолированы для изменений без снижения производительности.

Например. Допустим, вам нужно выполнить запрос A, который возвращает скалярное целое число.

Затем, позже требования меняются, и вы решаете, что результаты скаляра> x, что тогда, и только тогда вам нужно выполнить другой запрос. Если вы выполнили первый запрос в SP, вы могли легко проверить результат первого запроса и условно выполнить 2-й SQL в том же SP.

Как бы вы сделали это эффективно во встроенном SQL без выполнения отдельного или ненужного запроса?

Вот пример:

--This SP may return 1 or two queries. 

SELECT @CustCount = COUNT(*) FROM CUSTOMER 

IF @CustCount > 10 
   SELECT * FROM PRODUCT 

Может ли это / каков наилучший способ сделать это во встроенном SQL?

Answer 1

Очень убедительная статья

SQL и хранимые процедуры будут там на протяжении ваших данных.

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

Answer 2

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

Answer 3

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

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

Answer 4

В последнее время я предпочитаю не использовать SP (за исключением случаев, когда возникает сложность uber, когда процесс будет лучше ... или CLR будет лучше). Я использовал шаблон Repository с LINQ to SQL, где мой запрос записан на уровне данных в строго типизированном выражении LINQ. Ключевым моментом здесь является то, что запрос строго типизирован, что означает, что при рефакторинге я выполняю рефакторинг свойств класса, который непосредственно генерируется из таблицы базы данных (что делает изменения в БД, переносимые вперед, очень легкими и точными). В то время как мой SQL генерируется для меня и отправляется на сервер, у меня все еще есть возможность придерживаться принципов СУХОГО, так как шаблон репозитория позволяет мне разбить вещи на их наименьший компонент. У меня действительно есть проблема, что я мог бы совершить поездку на сервер и, основываясь на результатах запроса, я могу обнаружить, что мне нужно совершить еще одну поездку на сервер. Я не беспокоюсь об этом заранее. Если позже я обнаружу, что это становится проблемой, я могу преобразовать этот код в нечто более производительное. Главный ключ здесь в том, что не существует ни одной волшебной пули. Я склонен работать над новыми приложениями, что делает этот метод разработки наиболее эффективным для меня.

Answer 5

Преимущества ИП:

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

Недостатки:

1. Зависит от используемого движка базы данных
2. Делает развертывание обновлений немного сложнее (вам нужно развернуть приложение + скрипты)

Мои 2 цента ...

О вашем примере, это можно сделать так:

select * from products where (select count(*) from customers>10)

Answer 6

Возможно, включите предложение WHERE в этот sproc:

WHERE (all your regular conditions)
AND   myScalar > myThreshold

Answer 7

Как бы вы сделали это эффективно в встроенный SQL без выполнения отдельного запрос или ненужный запрос?

Зависит от базы данных, которую вы используете. В SQL Server это простой оператор CASE.