sql >> Base de Datos >  >> RDS >> Mysql

¿Deberían los desarrolladores de PHP usar los procedimientos almacenados de MySQL?

El uso o no de procedimientos almacenados es más una discusión religiosa o política en un bar que no hacerlo.
Lo que debe hacerse es definir claramente las capas de su aplicación y no traspasar esos límites. Los procedimientos almacenados tienen varias ventajas y desventajas con respecto a realizar consultas fuera de la base de datos.

Ventaja 1:los procedimientos almacenados son modulares. Esto es algo bueno desde el punto de vista del mantenimiento. Cuando surgen problemas de consulta en su aplicación, probablemente estará de acuerdo en que es mucho más fácil solucionar un procedimiento almacenado que una consulta incrustada enterrada dentro de muchas líneas de código GUI.

Ventaja 2:los procedimientos almacenados son ajustables. Al tener procedimientos que manejan el trabajo de la base de datos para su interfaz, elimina la necesidad de modificar el código fuente de la GUI para mejorar el rendimiento de una consulta. Se pueden realizar cambios en los procedimientos almacenados, en términos de métodos de combinación, tablas diferentes, etc., que son transparentes para la interfaz de usuario.

Ventaja 3:los procedimientos almacenados abstraen o separan las funciones del lado del servidor del lado del cliente. Es mucho más fácil codificar una aplicación GUI para llamar a un procedimiento que crear una consulta a través del código GUI.

Ventaja 4:Los procedimientos almacenados generalmente los escriben los desarrolladores/administradores de bases de datos. Las personas que ocupan estos roles suelen tener más experiencia en la escritura de consultas eficientes y sentencias SQL. Esto libera a los desarrolladores de aplicaciones GUI para utilizar sus habilidades en las piezas de presentación gráficas y funcionales de la aplicación. Si tiene a su gente realizando las tareas para las que mejor se adaptan, finalmente producirá una mejor aplicación general.

Con todo eso en mente, hay varias desventajas.

Desventaja 1:las aplicaciones que involucran una lógica y procesamiento de negocios extensos podrían generar una carga excesiva en el servidor si la lógica se implementara completamente en procedimientos almacenados. Los ejemplos de este tipo de procesamiento incluyen transferencias de datos, recorridos de datos, transformaciones de datos y operaciones computacionales intensivas. Debe mover este tipo de procesamiento a los componentes de lógica de acceso a datos o procesos comerciales, que son un recurso más escalable que su servidor de base de datos.

Desventaja 2:no coloque toda su lógica comercial en procedimientos almacenados. El mantenimiento y la agilidad de su aplicación se convierte en un problema cuando debe modificar la lógica de negocios en lenguaje Sp. Por ejemplo, las aplicaciones ISV que admiten múltiples RDBMS no deberían necesitar mantener procedimientos almacenados separados para cada sistema.

Desventaja 3:escribir y mantener procedimientos almacenados suele ser un conjunto de habilidades especializadas que no todos los desarrolladores poseen. Esta situación puede introducir cuellos de botella en el cronograma de desarrollo del proyecto.

Probablemente me he perdido algunas ventajas y desventajas, no dude en comentar.