При использовании последней версии драйвера jdbc для SQL Server 2005/2008 как сравниваются подготовленные операторы, представления и хранимые процедуры в отношении производительности?

Question

При использовании новейшего драйвера Microsoft jdbc для SQL Server 2005/2008 как сравниваются подготовленные операторы, представления и хранимые процедуры с точки зрения производительности?

Если у меня есть простой старый оператор select с некоторыми динамическими предложениями where, я увижу преимущества перехода от простого SQL в подготовленном операторе к представлению или даже к хранимой процедуре?

Чтобы быть более конкретным, что-то вроде этого:

select foo.name, bar.name, baz.name, belch.burp
from foo 
inner join bar on foo.id=bar.fooID
inner join baz on bar.id=baz.barID
inner join belch on baz.id = belch.bazID
where foo.name like '%<USERINPUT>%' and bar.name like '%<USERINPUT>%'

Answer 1

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

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

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

Ограничить чтение защищенных данных из операторов SELECT без необходимости назначения отдельных разрешений столбцов для базовых таблиц.

Повторно использовать параметризованные SP из другого кода SQL и нескольких мест в приложении.

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

Выполнить рефакторинг базы данных, не затрагивая и не повторно развертывая код приложения.

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

Answer 2

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

Answer 3

зависит от sql и вашего приложения. я не верю, что есть общий ответ, и он, вероятно, не зависит от водителя.

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