Запрос против хранимой процедуры; разница между двумя подходами

Question

Я разрабатываю веб-страницу для поиска. У меня есть два варианта создания этой страницы

1. Чтобы построить запрос на странице в соответствии с параметром, введенным пользователем, и отправить его на сервер.

2. Чтобы отправить параметры хранимой процедуре, создать запрос и выполнить его.

Я хочу знать, какой подход я должен принять и почему.

Я хочу знать преимущества или недостатки обоих подходов.

Answer 1

С моей стороны, процедура хранения будет хорошей.

1. Хранимая процедура не будет компилироваться снова и снова, когда каждый раз выполняется простая Query, а затем выполняется.

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

Answer 2

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

Также рассмотрите возможность установки optimize for ad hoc workloads option в 1. Следующее - от msdn

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

Ссылки:

1. оптимизация для специальных целейПараметр конфигурации сервера рабочих нагрузок
2. Почему бы НЕ использовать параметр SQL Server «оптимизировать для специальных рабочих нагрузок»?

Answer 3

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

Answer 4

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

Answer 5

При передаче запроса из внешнего интерфейса увеличивается вероятность внедрения SQL.Store prcedure предварительно компилируется, а запрос сначала компилируется, чем выполняется, поэтому вероятность синтаксической ошибки увеличивается

Answer 6

Используйте хранимые процедуры.Не потому, что они быстрее, а потому, что они обеспечивают выполнение контракта с базой данных (передайте хранимой процедуре эти параметры, и она вернет данные).

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

Также гораздо проще повторно использовать запросы / логику в хранимых процедурах для нескольких внешних интерфейсов.

Answer 7

Использование хранимой процедуры всегда лучше.

1) Если ваш запрос длинный, он потребляет ресурсы вашей сети. Когда мы отправляем большие запросы SQL по сетевому соединению, это увеличивает сетевой трафик.

2) Хранимые процедуры предварительно компилируются и сохраняются, поэтому они быстрее.

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

Answer 8

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