Разработчики PHP должны использовать хранимые процедуры MySQL? [закрытый]
7 ответов
Вопрос о том, использовать ли хранимые процедуры или нет, - это скорее религиозная или политическая дискуссия в баре, чем нет.
Что нужно сделать, так это четко определить уровни вашего приложения и не переступать через эти границы. Хранимые процедуры имеют несколько преимуществ и недостатков по сравнению с выполнением запросов вне базы данных.
Преимущество 1: Хранимые процедуры являются модульными. Это хорошо с точки зрения обслуживания. Когда в вашем приложении возникает проблема с запросом, вы, вероятно, согласитесь с тем, что гораздо проще устранить неполадки хранимой процедуры, чем встроенный запрос, скрытый во многих строках кода графического интерфейса.
Преимущество 2: хранимые процедуры настраиваются. Имея процедуры, которые обрабатывают работу с базой данных для вашего интерфейса, вы избавляетесь от необходимости изменять исходный код графического интерфейса пользователя для повышения производительности запроса. В хранимые процедуры можно вносить изменения - с точки зрения методов соединения, различных таблиц и т. Д. - которые прозрачны для внешнего интерфейса.
Преимущество 3: хранимые процедуры абстрагируют или отделяют серверные функции от клиентских. Намного проще написать приложение с графическим интерфейсом пользователя для вызова процедуры, чем строить запрос через код графического интерфейса.
Преимущество 4: Хранимые процедуры обычно пишутся разработчиками / администраторами баз данных.Лица, занимающие эти роли, обычно более опытны в написании эффективных запросов и операторов SQL. Это позволяет разработчикам приложений с графическим интерфейсом использовать свои навыки для функциональных и графических элементов представления приложения. Если у вас есть люди, выполняющие те задачи, для которых они лучше всего подходят, вы в конечном итоге создадите лучшее приложение в целом.
С учетом всего этого есть несколько недостатков.
Недостаток 1: Приложения, включающие обширную бизнес-логику и обработку, могут создать чрезмерную нагрузку на сервер, если логика полностью реализована в хранимых процедурах. Примеры этого типа обработки включают передачу данных, обход данных, преобразование данных и интенсивные вычислительные операции. Вам следует перенести этот тип обработки на компоненты бизнес-процесса или логики доступа к данным, которые являются более масштабируемым ресурсом, чем ваш сервер базы данных.
Недостаток 2: Не помещайте всю свою бизнес-логику в хранимые процедуры. Обслуживание и гибкость вашего приложения становятся проблемой, когда вы должны изменить бизнес-логику на языке Sp. Например, приложениям независимых поставщиков ПО, которые поддерживают несколько СУБД, не нужно поддерживать отдельные хранимые процедуры для каждой системы.
Недостаток 3: Написание и обслуживание хранимых процедур чаще всего являются специальным набором навыков, которым обладают не все разработчики. Эта ситуация может создать узкие места в графике разработки проекта.
Я, наверное, упустил некоторые преимущества и недостатки, не стесняйтесь комментировать.
Пару лет назад я написал изрядное количество (~ 3К строк) кода хранимых процедур для проекта PHP / MySQL. По моему опыту:
- Хранимые процедуры MySQL, вероятно, не помогут вам с точки зрения производительности.
- Выполнение SP через подготовленные операторы MySQLi может вызвать головную боль.
- Иногда бывает трудно абстрагироваться от общих закономерностей - я обнаружил, что повторяю себя больше, чем мне хотелось.
- В зависимости от версии и конфигурации MySQL вам могут потребоваться права
SUPERдля создания SP.
Если вы переносите код, использующий хранимые процедуры, проще всего их сохранить. Конечно, их можно использовать с PHP и MySQL, и я бы лично не назвал это нецелесообразным , в точности. Я бы просто, вероятно, не стал бы использовать их снова, если бы начинал новый проект PHP с нуля.
Хранимые процедуры - часто - пустая трата усилий.
Когда есть сомнения, измерьте производительность. Вы часто обнаружите, что хранимые процедуры усложняют систему, не принося никакой ощутимой пользы. Вы можете не получить никакого улучшения производительности от ваших SP.
Некоторые люди считают их очень "важными". Важно на самом деле измерять производительность, а не спорить и дискутировать.
Может также быть из-за того, что MySQL не получал хранимые процедуры до версии 5. Если вы используете подготовленный оператор, все должно быть в порядке ... просто не используйте встроенный SQL
Многие (большинство?) Веб-приложений используют уровень абстракции базы данных, чтобы позаботиться об уязвимостях внедрения и т. Д.
Если вы хотите использовать его для своего собственного приложения, обратите внимание на 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.
А как насчет SQL-инъекции? Процедуры позволяют выполнять вызов параметров в предложении WHERE, уменьшая опасность инъекций