Vistas y procedimientos almacenados en SQL

Una vista en SQL es una consulta guardada bajo un nombre, que a partir de entonces se puede utilizar como si fuera una tabla. Su propósito es encapsular y reutilizar consultas, especialmente aquellas que son complejas o que se repiten con frecuencia. La idea se entiende bien con un ejemplo: supongamos que a menudo se necesita obtener las ventas del mes actual junto con el nombre del cliente y del vendedor, lo que requiere una consulta con varias uniones entre tablas, filtros por fecha y quizá alguna agregación. En lugar de escribir esa consulta larga y complicada cada vez que se necesita, se define una sola vez como una vista con un nombre descriptivo, y a partir de ese momento obtener esos datos es tan sencillo como hacer una selección sobre el nombre de la vista, igual que si se consultara una tabla normal. Una característica importante que conviene entender es que una vista, en su forma habitual, no almacena datos por sí misma, sino que actúa como una ventana o un atajo: cada vez que se consulta la vista, la base de datos ejecuta por debajo la consulta que la define y devuelve resultados siempre actualizados a partir de las tablas reales subyacentes. Existe una variante llamada vista materializada que sí almacena físicamente el resultado calculado para acelerar el acceso, a cambio de tener que refrescarlo periódicamente para que no quede desactualizado. Las vistas aportan tres beneficios principales: simplifican, al ocultar la complejidad de una consulta tras un nombre claro; permiten reutilizar, al definir la lógica una sola vez y usarla en muchos sitios; y pueden servir para controlar el acceso, exponiendo a ciertos usuarios solo un subconjunto de columnas o filas.

Un procedimiento almacenado es un bloque de lógica guardado dentro de la propia base de datos, que puede contener varias operaciones y que se ejecuta invocándolo por su nombre. A diferencia de una consulta simple o de una vista, un procedimiento almacenado puede aceptar parámetros de entrada, contener estructuras de control como condiciones y bucles, realizar varias operaciones de forma coordinada, incluidas modificaciones de los datos, y devolver resultados. Es, en esencia, un pequeño programa que vive dentro de la base de datos y que encapsula una lógica concreta. Por ejemplo, un procedimiento podría encargarse de registrar el pago de un pedido, actualizando el importe pagado en la tabla de pedidos y registrando además un movimiento en una tabla de movimientos, todo en una sola operación invocable por su nombre con los parámetros correspondientes. La ventaja de los procedimientos almacenados es que permiten centralizar una lógica que, de otro modo, habría que repetir en cada aplicación o componente que accede a la base de datos, garantizando así que esa operación se realice siempre de la misma manera y en el lugar adecuado. También pueden ofrecer ventajas de rendimiento en ciertos casos, al ejecutarse cerca de los datos y evitar múltiples idas y vueltas entre la aplicación y la base de datos, y pueden contribuir a la integridad al agrupar operaciones que deben ocurrir juntas. La diferencia fundamental con una vista es que la vista encapsula una consulta orientada a leer y simplificar la obtención de datos, mientras que el procedimiento encapsula una lógica orientada a ejecutar operaciones, a menudo con varios pasos que modifican datos. Dicho esto, conviene usar los procedimientos con criterio y no volcar en ellos toda la lógica de una aplicación, por las dificultades de mantenimiento que ello acarrea.

La diferencia fundamental entre una vista y un procedimiento almacenado está en qué encapsula cada uno y para qué sirve. Una vista encapsula una consulta, es decir, está orientada a leer y a simplificar la obtención de datos: guarda bajo un nombre una consulta que puede ser compleja, y permite luego consultarla como si fuera una tabla, devolviendo un conjunto de resultados. Su naturaleza es esencialmente de lectura y de presentación de datos, actuando como una ventana sobre las tablas reales. Un procedimiento almacenado, en cambio, encapsula una lógica, es decir, está orientado a ejecutar operaciones: guarda un bloque de instrucciones que puede aceptar parámetros, incluir condiciones y bucles, y realizar varias acciones coordinadas, incluidas modificaciones de los datos. Su naturaleza es la de hacer cosas, no solo mostrarlas. Una forma sencilla de recordar la distinción es que la vista es para leer y el procedimiento es para hacer: si lo que se quiere es dar un nombre reutilizable a una consulta de la que se van a leer datos, se usa una vista; si lo que se quiere es encapsular una operación de varios pasos, especialmente si modifica datos, se usa un procedimiento. Hay también diferencias en cómo se usan: una vista se consulta con una selección, como una tabla, mientras que un procedimiento se ejecuta llamándolo por su nombre con sus parámetros. Ambos comparten el objetivo de reutilizar, simplificar y centralizar la lógica o las consultas dentro de la base de datos, evitando repetición, pero se aplican a necesidades distintas, la lectura simplificada en el caso de las vistas y la ejecución de operaciones en el de los procedimientos. Elegir el adecuado es cuestión de identificar si el objetivo es consultar o actuar.

Una vista normal, por sí sola, no mejora directamente el rendimiento, y es importante entender por qué para no tener expectativas equivocadas. Una vista habitual no almacena datos, sino que es esencialmente un nombre para una consulta guardada, de modo que cada vez que se consulta la vista, la base de datos ejecuta por debajo la consulta que la define, con el mismo coste que tendría escribir esa consulta directamente. Por tanto, usar una vista en lugar de escribir la consulta a mano no hace que la operación sea más rápida; su beneficio está en la comodidad, la reutilización y la claridad, no en la velocidad. De hecho, un uso descuidado de las vistas, como anidar muchas vistas unas sobre otras, puede incluso complicar el trabajo del optimizador de consultas y perjudicar el rendimiento si no se tiene cuidado. Ahora bien, existe una variante llamada vista materializada que sí puede mejorar el rendimiento de forma significativa. A diferencia de la vista normal, la vista materializada almacena físicamente el resultado de la consulta en el momento en que se calcula, de modo que las consultas posteriores leen ese resultado ya calculado en lugar de recomputar la consulta cada vez, lo que puede ser mucho más rápido para consultas costosas que se ejecutan con frecuencia. El precio de esta ventaja es que el resultado almacenado puede quedar desactualizado a medida que cambian los datos subyacentes, por lo que hay que refrescar la vista materializada periódicamente para mantenerla al día, lo que implica un coste y una decisión sobre cada cuánto hacerlo. En resumen, las vistas normales aportan claridad y reutilización pero no velocidad, mientras que las vistas materializadas sí pueden acelerar consultas costosas a cambio de gestionar su actualización, y para acelerar consultas la herramienta más habitual y directa siguen siendo los índices bien diseñados.

No, poner toda la lógica de una aplicación en procedimientos almacenados dentro de la base de datos no suele ser recomendable, y el consenso moderno se inclina por un enfoque equilibrado. Aunque los procedimientos almacenados tienen ventajas reales, como centralizar operaciones, garantizar que se ejecuten siempre igual, y a veces mejorar el rendimiento al estar cerca de los datos, también acarrean costes importantes si se abusa de ellos. La lógica que vive dentro de la base de datos es más difícil de gestionar en varios aspectos. Es más difícil de versionar, porque no se integra de forma natural con el control de versiones del código de la aplicación de la misma manera que el código normal, lo que complica seguir su historial y coordinar cambios. Es más difícil de probar, ya que las herramientas y prácticas de pruebas automatizadas están mucho más desarrolladas para el código de aplicación que para la lógica dentro de la base de datos. Es más difícil de depurar, porque las herramientas de depuración suelen ser más limitadas. Y ata la aplicación al motor de base de datos concreto, dificultando una eventual migración a otro, ya que los procedimientos suelen escribirse en lenguajes específicos de cada sistema. Por todo ello, la práctica recomendada es reservar las vistas y los procedimientos almacenados para aquello que se beneficia realmente de estar cerca de los datos, como consultas complejas y reutilizables o ciertas operaciones que requieren una integridad transaccional muy estrecha, y mantener la lógica de negocio general en la capa de la aplicación, donde es más fácil de mantener, probar, versionar y evolucionar. Se trata, en definitiva, de una cuestión de equilibrio: ni usar la base de datos para todo ni evitar por completo sus capacidades, sino elegir para cada pieza de lógica el lugar donde mejor encaja.

Sí, una de las utilidades valiosas y a menudo desaprovechadas de las vistas es el control de acceso a los datos, ya que permiten exponer a ciertos usuarios solo un subconjunto de la información, ocultando el resto. La idea es que, en lugar de dar a un usuario o a una aplicación acceso directo a una tabla completa con todas sus columnas y filas, se le da acceso a una vista definida de manera que muestre únicamente las columnas y las filas que esa parte debe ver, aplicando en la definición de la vista los filtros y la selección de columnas apropiados. Por ejemplo, si una tabla de empleados contiene tanto datos generales como información sensible relativa a salarios o datos personales, se puede crear una vista que exponga solo las columnas no sensibles, y conceder a determinados usuarios acceso a esa vista en lugar de a la tabla completa, de modo que nunca puedan ver la información reservada. Del mismo modo, se puede crear una vista que muestre solo las filas correspondientes a una región, un departamento o un cliente concreto, limitando así lo que cada usuario ve según su ámbito. Esta técnica combina el control de acceso con las demás ventajas de las vistas, como la simplificación y la reutilización, y encaja dentro del principio de mínimo privilegio, según el cual cada usuario debe tener acceso solo a lo estrictamente necesario para su función. Es importante tener en cuenta que el control de acceso mediante vistas suele complementarse con el sistema de permisos propio de la base de datos, que gestiona qué usuarios pueden acceder a qué objetos, y que ambos mecanismos trabajan juntos para proteger los datos. En conjunto, usar vistas para exponer versiones restringidas de los datos es una práctica útil y elegante que ayuda a proteger la información sensible sin renunciar a la comodidad de las consultas.