Я пишу приложения asp.net с задними концами SQL Server в течение последних 10 лет. За это время я также написал некоторые PHP-приложения, но не так много.
Я портирую некоторые из своих приложений asp.net на PHP и столкнулся с проблемой. В мире Asp.net обычно понимается, что при доступе к любым базам данных предпочтительным способом является использование представлений или хранимых процедур.
Я читал некоторые книги PHP / MySQL, и у меня складывается впечатление, что использование хранимых процедур в MySQL не рекомендуется. Я не решаюсь использовать это слово, желательно, но это только то чувство, которое я получаю.
Итак, совет, который я ищу, в основном, я прав или не прав? Разрабатывают ли PHP-разработчики хранимые процедуры вообще? Или это то, что избегает?
Является ли использование хранимых процедур или нет, скорее религиозная или политическая дискуссия в баре, чем нет.
Что нужно сделать, так это четко определить ваши уровни приложений, а не преодолевать эти границы. Хранимые процедуры имеют несколько преимуществ и недостатков, чем выполнение запросов за пределами базы данных.
Преимущество 1: Хранимые процедуры являются модульными. Это хорошо с точки зрения технического обслуживания. Когда возникает проблема с запросом в вашем приложении, вы, вероятно, согласитесь, что гораздо проще устранить неполадки хранимой процедуры, чем встроенный запрос, закодированный во многих строках кода GUI.
Преимущество 2: Сохраненные процедуры настраиваются. Имея процедуры, которые обрабатывают работу базы данных для вашего интерфейса, вы устраняете необходимость изменения исходного кода GUI для улучшения производительности запроса. Могут быть внесены изменения в хранимые процедуры – с точки зрения методов соединения, разных таблиц и т. Д. – которые прозрачны для интерфейсного интерфейса.
Преимущество 3: Сохраненные процедуры абстрактные или отдельные серверные функции с клиентской стороны. Гораздо проще закодировать приложение GUI для вызова процедуры, чем для создания запроса через код GUI.
Преимущество 4: Хранимые процедуры обычно записываются разработчиками / администраторами баз данных. Лица, занимающие эти роли, обычно более опытные в написании эффективных запросов и операторов SQL. Это позволяет разработчикам приложений GUI использовать свои навыки в функциональных и графических частях презентации приложения. Если у вас есть ваши люди, выполняющие задачи, к которым они наиболее подходят, тогда вы в конечном итоге получите лучшее общее приложение.
Имея это в виду, есть несколько недостатков.
Недостаток 1: Приложения, которые включают в себя обширную бизнес-логику и обработку, могут привести к чрезмерной нагрузке на сервер, если логика полностью реализована в хранимых процедурах. Примеры такого типа обработки включают передачу данных, обход данных, преобразование данных и интенсивные вычислительные операции. Вы должны переместить этот тип обработки в бизнес-процесс или компоненты логики доступа к данным, которые являются более масштабируемым ресурсом, чем ваш сервер базы данных.
Недостаток 2: Не помещайте всю свою бизнес-логику в хранимые процедуры. Техническое обслуживание и гибкость вашего приложения становятся проблемой, когда вы должны модифицировать бизнес-логику на языке Sp. Например, приложениям ISV, которые поддерживают несколько RDBMS, не нужно поддерживать отдельные хранимые процедуры для каждой системы.
Недостаток 3: Написание и сохранение хранимых процедур чаще всего является специализированным набором навыков, который не у всех разработчиков. Эта ситуация может ввести узкие места в график разработки проекта.
Я, вероятно, пропустил некоторые преимущества и недостатки, не стесняйтесь комментировать.
Также может быть потому, что MySQL не получал хранимые процедуры до версии 5. Если вы используете подготовленный оператор, вы должны быть в порядке … просто не используйте встроенный SQL
Пару лет назад я закончил писать довольно много (~ 3K строк) кода хранимой процедуры для проекта PHP / MySQL. По моему опыту:
SUPER для создания SP. Если вы портируете код, который использует хранимые процедуры, проще всего их сохранить. Конечно, можно использовать их с PHP и MySQL, и я не стал бы называть его нецелесообразным . Я просто, вероятно, не стал бы использовать их снова, если бы начинал новый PHP-проект с нуля.
Что такое SQL-инъекция? Процедуры позволяют выполнять вызов параметров в предложении WHERE, уменьшая риск заражения
Хранимые процедуры – часто – полная трата усилий.
Когда вы сомневаетесь, на самом деле измеряете производительность. Вы часто обнаружите, что хранимые процедуры добавляют сложность без каких-либо узнаваемых преимуществ. У вас не может быть повышения производительности от ваших SP.
Некоторые люди считают, что они очень «важны». Важно измерять производительность, а не каббл или дебаты.
Многие (большинство?) Webapps используют уровень абстракции базы данных, чтобы ухаживать за уязвимостями инъекций / и т. Д.
Если вы хотите использовать его для своего приложения, взгляните на PDO. Вот большой учебник о том, как его использовать: http://www.devshed.com/c/a/PHP/Using-PDO-Objects-in-PHP-5/
В общем, мне очень не нравятся хранимые процедуры, потому что:
Для любых манипуляций с базами данных я рекомендую перейти к инфраструктуре PHP ORM, например, http://www.doctrine-project.org или структуре, которая включает ORM, например CakePHP. У вас будет дополнительный бонус, позволяющий более легко переключаться между SQL Server и MySQL.
Вот сбалансированная и информированная статья о хранимых процедурах в MySQL: http://www.linuxjournal.com/article/9652?page=0,0
Увольнять их из-под контроля как «трату времени» или «трудно поддерживать» или «не предоставлять никакой реальной выгоды» в любой базе данных, а применение значительных размеров было бы очень неразумно.