Каковы преимущества создания хранимых процедур в SQL и MySQL?

У меня есть теоретический вопрос.

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

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

В чем преимущества использования хранимых процедур в этом случае? Или что лучше? Использовать функции в PHP или хранимые процедуры в базе данных? И каковы различия между ними?

Спасибо.

Ответ 1

Некоторые преимущества включают:

Поддержание работоспособности: вы можете изменить логику в процедуре без необходимости редактировать вызовы app1, app2 и app3.
Безопасность/Контроль доступа: легче беспокоиться о том, кто может вызывать предопределенную процедуру, чем контролировать, кто может получить доступ к тем таблицам или строкам таблицы.
Производительность: если ваше приложение не расположено на том же сервере, что и ваша БД, а то, что вы делаете, связано с несколькими запросами, использование процедуры уменьшает сетевые издержки за счет включения одного вызова в базу данных, а не сколько звонков, сколько есть запросов.
Производительность (2): план запроса процедуры обычно кэшируется, что позволяет повторно использовать его снова и снова, без необходимости его повторной подготовки.

(В случае вашего конкретного примера выгоды, по общему признанию, ноль.)

Ответ 2

Короткий ответ будет, если вы хотите, чтобы код был переносимым, не используйте хранимые процедуры, потому что если вы захотите в какой-то момент изменить базу данных, например, от MySQL до PostgreSQL, вам придется обновлять/переносить все сохраненные процедуры, которые вы написали.

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

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

Ответ 3

ok, это может быть немного упрощенным (и, возможно, неполным):

С хранимой процедурой:

вам не нужно передавать запрос в базу данных
СУБД не обязательно каждый раз проверять запрос (проверять в смысле синтаксиса и т.д.)
СУБД не нужно каждый раз оптимизировать запрос (помните, что SQL является декларативным, поэтому СУБД должен генерировать оптимизированный план выполнения запроса)

Ответ 4

Поскольку большинство из парней уже объясняли это, но все же я бы попытался повторить по-своему.

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

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

Итак, у нас есть:
Клиент ------------------------------------------------- --------- > Сервер

Обычный:
Запрос, созданный @Client ----------, затем распространится на сервер ---------- Запрос: Достигнутый сервер: проанализировать, скомпилировать, выполнить.

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

Преимущества:
Сокращение сетевого трафика. Если клиент отправляет большой запрос и может часто использовать один и тот же запрос, каждый бит запроса отправляется в сеть и, следовательно, может увеличить сетевой трафик и ненужное увеличение использования сети.
Быстрее выполнения запросов: поскольку хранимые процедуры обрабатываются, компилируются сразу, а исполняемый файл кэшируется в базе данных. Поэтому, если такой же запрос повторяется несколько раз, тогда база данных напрямую выполняет исполняемый файл и, следовательно, время сохраняется в Parse, Compile и т.д. Это хорошо, если запрос используется часто. Если запрос не используется часто, то это может быть не очень хорошо, потому что хранение кэшированного исполняемого файла занимает пробел, поэтому без необходимости загружать Load on Database.
Модульный: если несколько приложений хотят использовать один и тот же запрос, то традиционным способом вы дублируете код без необходимости в приложениях, путь заключается в том, чтобы поставить код близко к базе данных, таким образом, дублирование можно легко облегчить.
Безопасность. Сохраненные процедуры также разрабатываются с учетом авторизации (это значит, кто имеет привилегию запускать запрос, а кто нет). Так что для конкретного пользователя вы можете предоставить разрешения, другим, которые вы, как администратор базы данных, можете отозвать разрешение. Таким образом, это хороший способ, как точка для администраторов баз данных DBA, вы можете знать, кто является подходящим лицом для доступа. Но такие вещи сейчас не так популярны, вы можете создать свою базу данных приложений так, чтобы только уполномоченное лицо могло получить к ней доступ, а не все. Поэтому, если у вас есть только Security/Authorization в качестве точки использования хранимых процедур вместо обычного способа выполнения действий, тогда хранимая процедура может оказаться неприемлемой.