El uso de funciones, disparadores y procedimientos almacenados de MySQL tiene muchas ventajas, pero también algunos desafíos. Detallaremos estos diferentes puntos y veremos cómo evitar los pocos elementos que podrían causar problemas (versiones, pruebas unitarias, etc.).
Beneficios del uso de funciones, disparadores y procedimientos almacenados de MySQL
Si está en el contexto de una aplicación web en modo LAMP, con código PHP y una base de datos MySQL, tiene dos opciones al momento de implementar sus reglas comerciales. Crea métodos PHP en tus clases o usa funciones o procedimientos en MySQL. La cuestión de la elección a realizar puede plantearse legítimamente, teniendo cada uno de los métodos sus ventajas y desventajas.
Desarrollar en el lado de la base de datos tiene varias ventajas:
- Si estás como yo en un entorno mixto (servidores LAMP y servidores Microsoft con SQL Server y SSIS en particular), no podrás utilizar en SSIS por ejemplo los desarrollos que hayas hecho en PHP. Si bien podrá ejecutar y recuperar el conjunto de datos, su procedimiento almacenado le devolverá sin problemas. Esto te ahorrará, por tanto, tener que codificar dos veces lo mismo, además en dos entornos diferentes (con todos los problemas que esto te puede traer).
- Esto te da un plus en términos de seguridad , porque tus datos ya no son modificados en vivo por un código externo. Pasan por su capa de desarrollo de SQL, donde puede definir sus diversos controles. El disparador en el contexto de la seguridad de sus datos también es esencial, porque es el único que le permite controles que nunca pueden ser anulados.
- Las reglas de negocio están lo más cerca posible de los datos . Por lo tanto, esto evita que su procesamiento pase por todas las capas cada vez (navegador del lado del cliente, servidor web, intérprete de PHP y base de datos). Ya estás en el nivel más bajo.
Por lo tanto, está cerca de los datos, sus desarrollos son auténticos para garantizar la integridad de sus datos y también son reutilizables en diferentes aplicaciones y en diferentes entornos. Esa es la demanda de la gente.
Desventajas y soluciones alternativas
Acabas de ver que las ventajas eran numerosas y no despreciables. Sin embargo, esto no está exento de algunos problemas. Pero una vez que se integran estos problemas, se vuelve bastante simple proponer soluciones para enfrentarlos.
Versionado de código
Esta es una preocupación que se cita a menudo cuando se desarrolla en el lado de MySQL. El código de sus funciones, disparadores y procedimientos almacenados de MySQL no es versionable, y una vez cargado en su servidor web, siente que está «perdiendo el control» de su código.
Otro problema, si desea realizar una búsqueda completa dentro de su aplicación con su IDE favorito (por ejemplo, como parte de una refactorización de código que involucra un cambio de nombre en un campo), no verá el código MySQL.
La solución a este problema es bastante simple: debe integrar su código SQL en su aplicación y configurar un mecanismo para cargar su código en su base de datos.
Veamos esto con más detalle. Si tiene que crear una función, un disparador o un procedimiento almacenado de MySQL, creará el código en su IDE. Idealmente, deberías dedicar una carpeta a tu aplicación (llamémosla SQL), con subniveles que te permitan clasificarlos por tipo (función, disparador, vista, procedimiento) y con una estructura de árbol correspondiente a tu aplicación. Los archivos creados tendrán una extensión .sql (también se beneficiará del resaltado de sintaxis, o incluso de las correcciones de su IDE, que generalmente sabe cómo reconocer el lenguaje SQL).
Hará esto para todo su código SQL. Agregará su código a medida que avanza, agregando DROP y CREATE. También deberá definir un DELIMITADOR particular ($$ por ejemplo, o cualquier otro que esté seguro de no encontrar en su código SQL) que agregará después de la instrucción DROP y al final de su activador, función o procedimiento. MySQL almacenado.
Como es un archivo, podrá administrarlos en su herramienta de administración de versiones de código, por ejemplo con Git y SourceTree :
Ahora queda cargar este código en su base de datos.
Para hacer esto, solo necesita configurar un script que recupere sus archivos .sql (por ejemplo, con un RecursiveDirectoryIterator), los agregue en un archivo temporal (a través de file_put_contents, por ejemplo) y luego reproduzca este archivo en su base de datos (llamándolo mysql desde la línea de comandos). También puede colocar una plantilla de encabezado para el archivo temporal, incluida la instrucción DELIMITER para establecer el delimitador que ha elegido.
Si quiere ir un poco más allá, puede agregar argumentos a su secuencia de comandos. Por ejemplo, solo procesar funciones, procedimientos o disparadores. O incluso generar solo un archivo sql de agregación sin iniciarlo en la base de datos (para control).
Si realiza sus transiciones a producción a través de un repositorio de versiones, nada le impide configurar un script de producción. Iría y actualizaría la producción con el repositorio de su proyecto, y luego configuraría sus archivos sql.
Pruebas unitarias
Otra posible crítica al uso de disparadores, funciones y procedimientos almacenados de MySQL es la imposibilidad de integrarlos en sistemas automatizados de pruebas unitarias, lo que se puede hacer, por ejemplo, con Jenkins en un proceso de integración continua .
Es verdad. Por otro lado, si desarrolla una función MySQL, por ejemplo, existe una buena posibilidad de que luego se use en un método PHP que lo llamará pasando parámetros.
Sin embargo, este método PHP se puede llamar absolutamente en una prueba unitaria.
Por ejemplo, considere un procedimiento almacenado que actualiza los precios de un artículo. Lo desarrolló en MySQL porque puede ser llamado por diferentes herramientas. Y quería estar seguro de tener un único punto de paso para el cambio de precio. Este procedimiento puede ser llamado por el método majPrix de su clase de artículo de PHP, que puede probar individualmente.
Finalmente, si estamos hablando de pruebas unitarias (excluyendo aquí la integración continua), no hay nada más simple que probar un procedimiento almacenado de MySQL. Simplemente llámelo desde la línea de comando pasándole los parámetros correctos. Es incluso menos restrictivo que probar un método PHP. Nada impide incluso desarrollar un script SQL que permita probar con diferentes parámetros la llamada de una función o un procedimiento almacenado de MySQL.
Conclusión
Aquí te doy mi punto de vista. No dude en dejarme saber en los comentarios los suyos, sus comentarios u otras limitaciones que no figuran en la lista anterior.
