Decide con inteligencia: Stored procedures vs. SQL en tu código

Hubo una vez en la que me vi envuelto en una discusión sobre los méritos de los stored procedures en comparación con colocar SQL directamente en el código. El ambiente se asemejaba a un debate político acalorado, con cada lado presentando puntos válidos. Aquí están ambos lados de la discusión.

¿Dónde debería ir?

Es raro abordar un proyecto de desarrollo que no interactúe con una fuente de datos backend. Después de todo, los datos son la vida de una organización. Cuando creas una aplicación con una base de datos backend como SQL Server, el lenguaje de programación Transact-SQL (T-SQL) es la interfaz de programación principal entre tus aplicaciones y la base de datos de SQL Server.

Cuando se utilizan programas en T-SQL, hay dos métodos disponibles para almacenar y ejecutar los programas. Puedes almacenar los programas localmente y crear aplicaciones que envíen los comandos a SQL Server y procesen los resultados; o puedes almacenar los programas como stored procedures en SQL Server y crear aplicaciones que ejecuten los stored procedures y procesen los resultados.

Los stored procedures en SQL Server son similares a los procedimientos en otros lenguajes de programación en el sentido de que pueden:

• Aceptar parámetros de entrada y devolver múltiples valores en forma de parámetros de salida al procedimiento o lote que llama.
• Contener instrucciones de programación que realizan operaciones en la base de datos, incluyendo la llamada a otros procedimientos.
• Devolver un valor de estado a un procedimiento o lote que llama para indicar el éxito o el fracaso (y la razón del fracaso).

Tú tomas la decisión de interactuar con la base de datos backend a través de stored procedures o incluyendo el SQL en el código de tu aplicación. Vamos a analizar más de cerca cada enfoque.

Aprovecha SQL Server

Los beneficios de utilizar stored procedures en SQL Server en lugar de código de aplicación almacenado localmente en computadoras cliente incluyen:

Cómo instalar y configurar Sybase Adaptive Server Enterprise (ASE) en Linux

• Permiten la programación modular.
• Permiten una ejecución más rápida.
• Pueden reducir el tráfico de red.
• Pueden utilizarse como mecanismo de seguridad.

Puedes crear un stored procedure una vez, almacenarlo en la base de datos y llamarlo cualquier número de veces en tu programa. Alguien especializado en programación de bases de datos puede crear stored procedures, lo que permite que el desarrollador de aplicaciones se centre en el código en lugar de en el SQL. Puedes modificar los stored procedures de forma independiente del código fuente del programa, por lo que la aplicación no necesita volver a compilarse si el SQL se modifica.

Si la operación requiere una gran cantidad de código T-SQL o se realiza de forma repetitiva, los stored procedures pueden ser más rápidos que lotes de código T-SQL. Durante la creación, los stored procedures se analizan y optimizan, y puedes utilizar una versión en memoria del procedimiento después de que se ejecute por primera vez. Cada vez que se ejecuta una instrucción T-SQL desde el cliente, SQL Server compila, optimiza y ejecuta la instrucción.

Puedes realizar una operación que requiere cientos de líneas de código T-SQL a través de una sola instrucción que ejecuta el código en un procedimiento, en lugar de enviar cientos de líneas de código a través de la red.

Además, puedes conceder permisos a los usuarios para ejecutar un stored procedure incluso si no tienen permiso para ejecutar las instrucciones del procedimiento directamente.

Colocar SQL en tu código

Aunque los stored procedures ofrecen una serie de beneficios, colocar SQL directamente en el código de tu aplicación no es necesariamente incorrecto. Un excelente ejemplo es el SQL que se genera dinámicamente. Su naturaleza dinámica anula muchas de las ventajas de un stored procedure.

Es decir, no puedes crear y almacenar en caché un plan de ejecución ya que es diferente cada vez que se llama. En este escenario, te enfrentas a la tarea de ensamblar el SQL en tu código o utilizar el comando T-SQL exec (o el stored procedure del sistema sp_executesql). La diferencia en este escenario es dónde se ejecuta el código (es decir, en el servidor), por lo que la decisión final dependerá de tu entorno.

Qué es sudo y por qué deberías usarlo

Otra situación en la que puedes tener que decidir entre construir T-SQL dinámico en tu aplicación o en el servidor de base de datos es al pasar datos al stored procedure. La naturaleza dinámica de la llamada a la base de datos implica que debes basar tu decisión en los valores de los datos, entre otras cosas. Por ejemplo, ¿quieres pasar valores de datos a un stored procedure del backend o utilizar los valores en el código de la aplicación para construir la cadena T-SQL?

Elige tu arma

Ambos lados de este debate tienen puntos válidos, pero la decisión final depende de tu situación. Asegúrate de no quedar encasillado debido a la falta de conocimiento de otro enfoque. Por ejemplo, he visto stored procedures que contienen más de siete páginas de código T-SQL. Podrías dividir la funcionalidad fácilmente, delegando parte del procesamiento al servidor de aplicaciones y reduciendo el tamaño del stored procedure.

Por otro lado, conozco a muchos desarrolladores que odian (o temen) T-SQL; escriben todas sus llamadas a la base de datos en su código de aplicación. Si bien esto funciona, elimina al servidor de base de datos de la imagen. Debes aprovechar la potencia de procesamiento del servidor de base de datos cuando sea posible, ya que descarga el procesamiento de tu aplicación.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Gestión de datos, allí encontraras muchos artículos similares a Decide con inteligencia: Stored procedures vs. SQL en tu código , tenemos lo ultimo en tecnología 2023.