En SQL Server, hay ciertos conceptos que uno se encuentra tarde o temprano, tanto si empieza en el mundo de las bases de datos como si ya lleva un tiempo peleándose con entornos reales. Los procedimientos almacenados y las funciones son dos de ellos. Ambos permiten encapsular lógica en T-SQL, ambos pueden reutilizarse y ambos tienen su lugar. Pero no son lo mismo. Y tratarlos como si lo fueran es una fuente constante de confusión, errores y, en muchos casos, de mal rendimiento.
Este artículo no busca hacer una comparativa teórica más. Aquí vamos a ver en qué se diferencian realmente, cuándo conviene usar uno u otro, qué limitaciones tiene cada uno y qué errores son más comunes al trabajar con ellos. Si estás empezando con SQL Server, esto es una base fundamental. Y si ya llevas tiempo en el oficio, probablemente te encuentres con más de una práctica que conviene revisar.
Entendiendo la diferencia de base
Aunque en la teoría tanto procedimientos como funciones son objetos reutilizables de código T-SQL, en la práctica se comportan de forma muy distinta, sobre todo cuando hablamos de rendimiento, transaccionalidad, side effects y cómo se integran en una consulta.
Un procedimiento almacenado (Stored Procedure) es una secuencia de instrucciones T-SQL que se ejecuta como un bloque, puede devolver conjuntos de resultados, manejar errores, abrir y cerrar transacciones y, en general, actuar con bastante libertad. Como un EXEC.
Una función (Function), por otro lado, devuelve siempre un valor. Puede ser escalar (un solo valor) o con valores de tabla (inline o multisentencia). Se puede usar dentro de consultas como si fuera una expresión más. Y ahí empiezan los problemas.
Procedimientos almacenados: el «hombre para todo» de SQL Server
Los procedimientos almacenados llevan décadas siendo el núcleo de la lógica de negocio en la base de datos. Y aunque ahora todo el mundo quiere microservicios, orquestadores y que “la lógica viva fuera del SQL”, lo cierto es que los procedimientos siguen siendo una herramienta potentísima.
Pueden contener lógica compleja, trabajar con múltiples tablas, ejecutar DML (INSERT, UPDATE, DELETE), manejar cursores (sí, también hay gente que todavía los usa), y lo más importante: pueden tener efectos secundarios. De hecho, están pensados para eso.
Además, permiten declarar variables, manejar errores con TRY…CATCH, lanzar mensajes de error personalizados con RAISERROR o THROW, abrir transacciones, hacer ROLLBACK, hacer COMMIT, y todo esto mientras devuelven múltiples conjuntos de resultados si hace falta. No es elegante, pero es potente. Como un martillo neumático.
Funciones: elegantes, encapsuladas… y peligrosas
Las funciones escalar (Scalar-valued Functions, SVF) son atractivas. Parecen limpias, reusables, encapsulan lógica, se integran perfectamente en consultas… y luego te destruyen el rendimiento. Así, sin más.
El problema es que las SVF tradicionales se evalúan por cada fila de la consulta donde se usan. Y no, no se «inlinean» automáticamente (al menos no hasta SQL Server 2019 con INLINE y aún así, con limitaciones). Esto significa que si tienes una tabla con 10 millones de filas y usas una función escalar en el SELECT, estás ejecutando esa función… 10 millones de veces. Lo que se dice un plan brillante.
¿Y las funciones con valores de tabla? Aquí hay dos tipos: las inline TVF (Returns Table) y las multisentencia (Returns @Table con BEGIN…END). Las inline funcionan como una vista parametrizada, y eso está bien. Se comportan bien con el optimizador. Las multisentencia, en cambio, generan estimaciones de cardinalidad basura y planes horribles, porque el optimizador no tiene ni idea de lo que pasa dentro. Pero tú tampoco, así que estáis empatados.
Principales diferencias técnicas y funcionales
A nivel práctico, aquí van algunas diferencias que conviene no olvidar cuando te enfrentas al dilema función vs procedimiento:
- Un procedimiento no se puede usar en un SELECT. No devuelve un valor directamente. Se ejecuta con EXEC.
- Una función no puede tener side effects: no puede modificar datos (excepto si es una CLR, que eso es otra historia). Tampoco puede llamar a procedimientos, usar TRY…CATCH, ni realizar cambios en el estado de la base de datos.
- Las funciones escalar tradicionales matan el paralelismo de las consultas y generan estimaciones de coste que parecen salidas de un generador aleatorio.
- Los procedimientos pueden devolver múltiples conjuntos de resultados. Las funciones no.
- El plan de ejecución de una función escalar no se ve dentro del plan de ejecución de la consulta (hasta SQL Server 2019 sin INLINE). Así que diagnosticar problemas es como hacer cirugía a ciegas.
- Las funciones inline TVF sí se comportan bien en los planes de ejecución, porque se expanden como si fueran vistas. Y eso las hace usables en entornos serios.
Rendimiento: el gran elefante en la sala
Nadie crea funciones para que vayan lentas, pero casi todas acaban siéndolo. La causa es bien conocida: cada ejecución de una función escalar es un contexto separado. Si haces un SELECT que usa una función escalar sobre una tabla de millones de filas, estás pidiendo al motor que salte de contexto millones de veces. En vez de vectorizar el acceso, va fila a fila. Y sí, esto se nota.
En cambio, un procedimiento bien diseñado que trabaje con conjuntos puede procesar la misma lógica de forma mucho más eficiente. Y, sobre todo, puedes verlo venir en el plan de ejecución. No te lo oculta como si fuera un secreto de Estado.
Desde SQL Server 2019 se introdujo la inlining de funciones escalares (Scalar UDF Inlining) para funciones marcadas como SCHEMABINDING, sin lógica demasiado compleja y sin referencias a objetos no deterministas. Pero si la función tiene más de una variable o usa GETDATE(), ya estás fuera del juego.
Así que sí, puedes confiar en la mejora… pero más te vale leer la letra pequeña.
Casos de uso típicos (sin liarla)
Entonces, ¿cuándo usar uno y cuándo otro? Vamos al grano.
Usa procedimientos almacenados cuando necesitas lógica compleja, efectos secundarios, manejar errores, o quieres ejecutar bloques de operaciones que se comporten como transacciones. Ideal para llamadas desde aplicaciones, cargas ETL, tareas programadas, o cualquier situación donde el código no esté embebido en un SELECT.
Usa funciones inline con valores de tabla cuando necesites lógica reutilizable que se integre en consultas y no afecte negativamente al rendimiento. Si puedes expresarlo como una única SELECT y devolver una tabla sin BEGIN…END, adelante. Son tus amigas.
Evita funciones escalares tradicionales en cualquier sitio donde importe el rendimiento. O al menos, haz pruebas serias antes de meterlas en producción y que te explote todo el lunes por la mañana.
La trampa de la reutilización mal entendida
Una de las razones por las que se abusa de las funciones es el deseo de reutilizar lógica. Loable, pero mal ejecutado. Si una función contiene una consulta pesada que se va a ejecutar por cada fila, lo que tienes no es reutilización, es una trampa mortal.
A veces es mejor duplicar una expresión compleja dentro de dos consultas que encapsularla en una función escalar. Lo segundo parece más limpio, sí. Pero cuando empiecen las quejas de rendimiento, lo primero será más fácil de optimizar.
La clave está en saber cuándo sacrificar limpieza por control. Y no siempre la opción «bonita» es la correcta.
Conclusión
La diferencia entre procedimientos almacenados y funciones no es solo cuestión de sintaxis, sino de mentalidad. Si quieres control, potencia y libertad, usa procedimientos. Si necesitas expresividad dentro de consultas y sabes lo que estás haciendo, usa funciones inline. Pero si tu objetivo es reutilizar lógica sin entender el coste, acabarás con un sistema lento, opaco y lleno de problemas difíciles de rastrear.
Y si aún dudas, recuerda esto: un procedimiento bien hecho es un aliado; una función escalar mal usada es una bomba de relojería con apariencia de buen código. Tú decides qué prefieres tener en tu entorno.
