Должны ли разработчики PHP использовать хранимые процедуры MySQL?

Я пишу приложения asp.net с задними концами SQL Server в течение последних 10 лет. За это время я также написал несколько приложений для PHP, но не так много.

Я портирую некоторые из своих приложений asp.net на PHP и столкнулся с проблемой. В мире Asp.net обычно понималось, что при доступе к любым базам данных предпочтительным способом является использование представлений или хранимых процедур.

Я читал некоторые книги PHP/MySQL, и у меня складывается впечатление, что использование хранимых процедур в MySQL не рекомендуется. Я не решаюсь использовать это слово, желательно, но это только то чувство, которое я получаю.

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

Ответы

Ответ 1

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

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

Преимущество 2: Сохраненные процедуры настраиваются. Имея процедуры, которые обрабатывают работу базы данных для вашего интерфейса, вы устраняете необходимость изменения исходного кода GUI для повышения производительности запросов. Изменения могут быть внесены в хранимые процедуры - с точки зрения методов соединения, разных таблиц и т.д. - которые прозрачны для интерфейсного интерфейса.

Преимущество 3: Сохраненные процедуры абстрактные или отдельные серверные функции с клиентской стороны. Гораздо проще закодировать приложение GUI для вызова процедуры, чем для создания запроса через код графического интерфейса.

Преимущество 4: Хранимые процедуры обычно записываются разработчиками/администраторами баз данных. Лица, занимающие эти роли, обычно более опытные в написании эффективных запросов и операторов SQL. Это позволяет разработчикам приложений GUI использовать свои навыки в функциональных и графических частях презентации приложения. Если у вас есть ваши люди, выполняющие задачи, к которым они наиболее подходят, тогда вы в конечном итоге получите лучшее общее приложение.

Учитывая все это, есть несколько недостатков.

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

Недостаток 2: Не помещайте всю свою бизнес-логику в хранимые процедуры. Техническое обслуживание и гибкость вашего приложения становятся проблемой, когда вы должны модифицировать бизнес-логику на языке Sp. Например, приложениям ISV, которые поддерживают несколько RDBMS, не нужно поддерживать отдельные хранимые процедуры для каждой системы.

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

Я, вероятно, пропустил некоторые преимущества и недостатки, не стесняйтесь комментировать.

Ответ 2

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

Ответ 3

Пару лет назад я закончил писать довольно много (~ 3K строк) кода хранимой процедуры для проекта PHP/MySQL. По моему опыту:

  • Хранимые процедуры MySQL, вероятно, не помогут вам в производительности.
  • Выполнение SP с помощью подготовленных операторов с MySQLi может вызвать головные боли.
  • Трудно абстрагироваться от общих паттернов - я обнаружил, что повторяю себя больше, чем мне нравится.
  • В зависимости от версии и конфигурации MySQL вам могут потребоваться привилегии SUPER для создания SP.

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

Ответ 4

Как насчет внедрения SQL? Процедуры позволяют выполнять вызов параметров в предложении WHERE, уменьшая опасность заражения

Ответ 5

Хранимые процедуры - часто - полная трата усилий.

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

Некоторые считают, что они очень "важны". Это важно, чтобы на самом деле измерить производительность, а не каббл или дебаты.

Ответ 6

Многие (большинство?) webapps используют уровень абстракции базы данных, чтобы ухаживать за уязвимостями инъекций/и т.д.

Если вы хотите использовать его для своего приложения, взгляните на PDO. Вот большой учебник о том, как его использовать: http://www.devshed.com/c/a/PHP/Using-PDO-Objects-in-PHP-5/

Ответ 7

В общем, мне очень не нравятся хранимые процедуры, потому что:

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

Для любых манипуляций с базами данных я рекомендую использовать фреймворк PHP ORM, например http://www.doctrine-project.org или фреймворк, который включает ORM, например CakePHP. У вас будет дополнительный бонус, позволяющий более легко переключаться между SQL Server и MySQL.

Ответ 8

Вот сбалансированная и информированная статья о хранимых процедурах в MySQL: http://www.linuxjournal.com/article/9652?page=0,0

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