Cursores

Cursor

En bases de datos, el término cursor se refiere a una estructura de control utilizada para el recorrido (y potencial procesamiento) de los registros del resultado de una consulta.

Un cursor se utiliza para el procesamiento individual de las filas devueltas por el sistema gestor de base de datos para una consulta. Es necesario debido a que muchos lenguajes de programación sufren de lo que en inglés se conoce como impedance mismatch. Por norma general los lenguajes de programación son procedurales y no disponen de ningún mecanismo para manipular conjuntos de datos en una sola instrucción. Debido a ello, las filas deben ser procesadas de forma secuencial por la aplicación. Un cursor puede verse como un iterador sobre la colección de filas que habrá en el set de resultados.

Existen sentencias SQL que no requieren del uso de cursores. Ello incluye la sentencia Insert, así como la mayoría de formas del Update o el Delete. Incluso una sentencia Select puede no requerir un cursor si se utiliza en la variante de SELECT...INTO, ya que esta variante sólo devuelve una fila

Trabajando con cursores

Esta sección introduce la forma en la que los cursores deberían ser utilizados en aplicaciones con SQL empotrado, según el estándar SQL: 2003. No todas las capas de aplicación para sistemas de bases de datos relacionales siguen este estándar, utilizando en su lugar una interfaz diferente, como CLI o JDBC.

Un cursor es creado utilizando la sentencia DECLARE CURSOR. Es obligatorio asignarle un nombre.

 DECLARE cursor_name CURSOR FOR SELECT... FROM...

Antes de ser utilizado, el cursor debe ser abierto con una sentencia OPEN. Como resultado de esta sentencia, el cursor se posiciona antes de la primera fila del set de resultados.

 OPEN cursor_name

Un cursor se posiciona en una fila específica del set de resultados con la sentencia FETCH. Una sentencia fetch transfiere la información de la fila a la aplicación. Una vez todas las filas han sido procesadas o la sentencia fetch queda posicionada en una fila no existente (ver cursores de recorrido más abajo), el SGBD devuelve un SQLSTATE '02000' (acompañado normalmente de un SQLCODE +100) para indicar el final del set de resultados.

 FETCH cursor_name INTO...

El último paso consiste en cerrar el cursor utilizando la sentencia CLOSE.

 CLOSE cursor_name

Una vez un cursor está cerrado puede reabrirse de nuevo, lo cual implica que la consulta es reevaluada y se crea un nuevo set de resultados.

Desventajas de los cursores

Recuperar una fila del cursor puede resultar en un retraso, conocido en inglés como network round trip, y que se debe al tiempo necesario para enviar la petición al SGBD y esperar los datos. Ello supone la utilización de mucho más ancho de banda de la red de lo que se necesitaría por norma general para ejecutar una sola sentencia SQL como DELETE. Repetidos network round trips pueden suponer un impacto severo en la velocidad de operación del cursor. Algunos SGBD intentan minimizar este impacto utilizando el fetch de bloque. Un fetch de bloque implica que se envían múltiples filas o registros de forma conjunta desde el servidor al cliente. El cliente almacena el bloque de fila en un buffer local y recupera las filas desde el mismo hasta que el buffer está vacío.

Los cursores reservan recursos en el servidor, como por ejemplo locks, packages, procesos, almacenamiento temporal, etc. Por ejemplo, Microsoft SQL Server implementa los cursores creando una tabla temporal y rellenándola con los datos de la consulta. Si un cursor no se cierra de manera correcta, el recurso no será liberado hasta que la sesión SQL (conexión) sea cerrada. Este desperdicio de recursos en el servidor puede llevar no sólo a una degradación del rendimiento, sino también a fallos más graves.

 Ejemplo de cursores