Bueno siempre que he desarrollado en PHP con Base de Datos, lo he hecho utilizando MySQL y por lo general he formado mis consultas sql en una variable de PHP y después la envío al BD para su ejecución, al menos en los proyectos grandes que en los que trabajo y he trabajado era así debido a que empezaron en la versión 4 de MySQL donde no había ni Funciones ni Procedimientos Alamacenados (Stored Procedures/SP ), en mis proyectos chicos y de no mucha importancia he usado la versión 5 y he probado el placer de usar estas delicias (¬¬).
En mi trabajo estoy por comenzar un proyecto nuevo y de mucha importancia en el cuál podre utilizar esta versión y así poder gozar de los beneficios que tienen estas monadas como:
Fácil de Gestionar: se puede abstraer la lógica de negocio generando un estilo API y así se reduce el código fuente en la aplicación cliente. en mi caso el PHP
Seguridad: esto esta genial ya que se puede configurar el MySQL para que los usuarios puedan ejecutar uno o varios SPs y aunque el usuario no tenga acceso a las tablas el SP podrá ejecutarse sin problema, una buena práctica que he usado en mis sistemillas de prueba es que el usuario que conecta con la BD desde el PHP tenga permiso de ejecutar solo SP.
Centralización de Rutinas: hay ocasiones en las que tenemos a mas de una aplicación que explota la BD, en estos casos algunas rutinas que son exactamente iguales se necesitan en 2 o mas aplicaciones y cuando esto sucede tenemos que portar la rutina que ya habíamos escrito a la otra aplicación, pero con los SP como todo esta en la BD, estos pueden ser ejecutados por cualquier aplicación que tenga la habilidad de trabajar con MySQL 5, de esto modo solo se invoca al SP y listo, nos ahorramos unas cuantas líneas de código.
Menos tráfico de red: en lugar de formar dinámicamente una mega sentencia de SQL en la capa de Negocio y mandarla al MySQL, se puede escribir un SP y en la capa de Negocio solamente mandamos el nombre del SP para que ejecute esa mega sentencia que ya esta local a la BD, esto en redes locales no tiene mucha diferencia pero en redes WAN será la maravilla.
Encapsulamiento: pues como he dicho en las anteriores, los trozos de código se pueden encapsular para que se invoquen con un nombre y/o parámetros, el usuario del SP no tiene que sabe que es lo que hace para que la respuesta le sea útil.
Pero no todo es color de rosa ya que al usar esto perdemos la capacidad de escalar la BD a otra mas potente:
Reducción de la escalabilidad: debido a que todo esta en la BD al migrar a otro DBMS tendremos que reescribir la totalidad de los SP existentes ya que el lenguaje de programación de estos no son compatibles con los de otros fabricantes de Bases de Datos.
Y también esta esto que leí en un documento de Julián Butti que anda por ahí en la red , lo pego tal cual:
Ejecución centralizada en el Servidor: Esta ejecución puede verse como una ventaja o desventaja dependiendo de los recursos con los que se cuenta. La ventaja es que cuando está en acción, en respuesta a una petición de usuario, el procedimiento almacenado corre directamente bajo el control del motor de bases de datos, generalmente en un servidor separado aumentando con ello, generalmente, la rapidez del procesamiento del requerimiento. El gestor de la base de datos tiene acceso directo a los datos necesarios y solo necesita enviar el resultado final al usuario. Esto disminuye o evita por completo los gastos de red. Sin embargo, esto puede verse como una desventaja ya que hay que tener en cuenta que la innecesaria o excesiva declaración de procedimientos de ejecución en el gestor de bases de datos puede ser perjudicial, en general, para el rendimiento del servidor.
Pero bueno como no pienso cambiar a otra BD si acaso a la de MySQL Enterprise esta última me tiene sin cuidado 
la instrucción es clara y si no click 