У меня есть теоретический вопрос.
Я не вижу различий между объявлением функции в файле PHP и созданием хранимой процедуры в базе данных, которая делает то же самое.
Почему я хочу создать хранимую процедуру, чтобы, например, вернуть список всех городов для конкретной страны, когда я могу сделать это с помощью функции PHP для запроса базы данных и будет иметь тот же результат?
Каковы преимущества использования хранимых процедур в этом случае? Или что лучше? Использовать функции в PHP или хранимые процедуры в базе данных? И каковы различия между ними?
Спасибо.
Некоторые преимущества включают:
Поддержание работоспособности: вы можете изменить логику в процедуре без необходимости редактировать вызовы app1, app2 и app3.
Безопасность / Контроль доступа: легче беспокоиться о том, кто может вызывать предопределенную процедуру, чем контролировать, кто может получить доступ к тем таблицам или строкам таблицы.
Производительность: если ваше приложение не расположено на том же сервере, что и ваша БД, а то, что вы делаете, связано с несколькими запросами, использование процедуры уменьшает сетевые издержки за счет включения одного вызова в базу данных, а не столько звонков, сколько есть запросы.
Производительность (2): план запросов процедуры обычно кэшируется, что позволяет повторно использовать его снова и снова, не перерабатывая его повторно.
(В случае вашего конкретного примера выгоды, по общему признанию, равны нулю).
Короткий ответ был бы, если вы хотите, чтобы код был переносимым, не используйте хранимые процедуры, потому что если вы захотите в какой-то момент изменить базу данных, например, от MySQL до PostgreSQL, вам придется обновлять / переносить все сохраненные процедуры, которые вы написали.
С другой стороны, иногда вы можете добиться более высоких результатов производительности, используя хранимые процедуры, потому что весь этот код будет работать с помощью механизма базы данных. Вы также можете ухудшить ситуацию, если хранимые процедуры будут использоваться ненадлежащим образом.
Я не думаю, что выбор страны – очень дорогостоящая операция. Поэтому, я думаю, вам не нужно использовать хранимые процедуры для этого случая.
нормально, это может быть немного упрощенным (и, возможно, неполным):
С хранимой процедурой:
Поскольку большинство ребят уже объясняли это, но все же я бы попытался повторить по-своему
Хранимые процедуры :
Логика находится в базе данных.
Давайте скажем некоторые запросы, которые нам нужно выполнить, тогда мы можем это сделать либо:
Другой способ заключается в размещении запроса на сервере DataBase и создании псевдонимов для запроса, который клиент будет использовать для отправки запроса на сервер базы данных, а когда он будет получен на сервере, он будет выполнен.
Таким образом, мы имеем:
Клиент ————————————————- ———> Сервер
Обычный:
Запрос, созданный @Client ———-, затем распространится на сервер ———- Запрос: Достигнутый сервер: проанализировать, скомпилировать, выполнить.
Хранимые процедуры :
Создается псевдоним, используемый клиентом —————- затем протаживать сервер ——– Псевдоним, достигнутый на сервере: парсинг, скомпилированный, кэшированный (в первый раз )
В следующий раз, когда появится тот же псевдоним, выполните непосредственно исполняемый файл запроса.
Преимущества:
Сокращение сетевого трафика : если клиент отправляет большой запрос и может часто использовать один и тот же запрос, каждый бит запроса отправляется в сеть и, следовательно, может увеличить сетевой трафик и ненужное увеличение использования сети.
Более быстрое выполнение запроса : поскольку хранимые процедуры обрабатываются, компилируются сразу, а исполняемый файл кэшируется в базе данных. Поэтому, если один и тот же запрос повторяется несколько раз, то база данных напрямую выполняет исполняемый файл и, следовательно, время сохраняется в Parse, Compile и т. Д. Это хорошо, если запрос используется часто. Если запрос часто не используется, это может быть не очень хорошо, потому что сохранение кэшированного исполняемого файла занимает пробел, поэтому без необходимости загружать Load on Database.
Модульная : если несколько приложений хотят использовать один и тот же запрос, то традиционным способом вы дублируете код без необходимости в приложениях, лучший способ – поставить код близко к базе данных, таким образом, дублирование можно легко облегчить.
Безопасность . Сохраненные процедуры также разрабатываются с учетом авторизации (означает, кто имеет привилегию запускать запрос, а кто нет). Так что для конкретного пользователя вы можете предоставить разрешения, другим вы, поскольку администратор базы данных может отменить это разрешение. Таким образом, это хороший способ, как точка для администраторов баз данных DBA, вы можете знать, кто является подходящим лицом для доступа. Но такие вещи сейчас не так популярны, вы можете создать свою базу данных приложений так, чтобы только уполномоченное лицо могло получить к ней доступ, а не все. Поэтому, если у вас есть только Security / Authorization как точка для использования хранимых процедур вместо обычного способа делать что-то, тогда хранимая процедура может оказаться неприемлемой.