Cursor (base de datos)

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 solo devuelve una fila.

Trabajando con cursores

[editar]

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 revaluada y se crea un nuevo set de resultados.

Cursores de recorrido

[editar]

Los cursores pueden declararse como de recorrido o no. Si son de recorrido, éste indica la dirección en la que el cursor puede moverse.

Un cursor sin recorrido (non-scrollable en inglés) también se conoce como cursor unidireccional (forward-only en inglés). Cada fila puede ser leída como mucho una vez, y el cursor automáticamente se mueve a la siguiente fila. Una operación de fetch después de haber recuperado la última fila posiciona el cursor detrás de la misma y devuelve SQLSTATE 02000 (SQLCODE +100).

Un cursor de recorrido puede posicionarse en cualquier parte del set de resultados utilizando la sentencia SQL FETCH. La palabra clave debe ser especificada cuando se declare el cursor. El valor por defecto es NO SCROLL, aunque algunas capas de aplicación para bases de datos como JDBC pueden aplicar un valor por defecto diferente. 

 DECLARE cursor_name sensitivity SCROLL CURSOR FOR SELECT... FROM...

La posición de un cursor de recorrido puede especificarse de forma relativa a la posición actual del cursor o de forma absoluta a partir del principio del set de resultados. 

 FETCH [ NEXT | PRIOR | FIRST | LAST ] FROM cursor_name

 FETCH ABSOLUTE n FROM cursor_name

 FETCH RELATIVE n FROM cursor_name

Los cursores de recorrido pueden potencialmente acceder a la misma fila del set de resultados múltiples veces. Por lo tanto, modificaciones de datos (insert, update, delete) realizadas por otras transacciones podrían tener un impacto en el set de resultados. Un cursor puede ser sensible o insensible a tales modificaciones. Un cursor sensible recogería las modificaciones que afectarían al set de resultados, mientras que uno insensible no. Adicionalmente, un cursor puede ser asensible, en cuyo caso el SGBD intentará, en la medida de lo posible, aplicar los cambios como si fuera sensible.

WITH HOLD

[editar]

Por norma general los cursores son cerrados automáticamente al final de una transacción, es decir, cuando se ejecuta un COMMIT o un ROLLBACK, o bien cuando se da un cierre implícito de la transacción. Este comportamiento puede ser cambiado si el cursor es declarado utilizando la cláusula WITH HOLD (por defecto cualquier cursor será WITHOUT HOLD). Un cursor declarado con esta cláusula se mantiene abierto tras un COMMIT y se cierra después de un ROLLBACK, aunque algunos SGBD se desvían de este comportamiento estándar y mantienen abierto estos cursores después de un ROLLBACK. 

 DECLARE cursor_name CURSOR WITH HOLD FOR SELECT... FROM...

Cuando se ejecuta un COMMIT, el cursor WITH HOLD se posiciona antes de la siguiente fila o registro. Por lo tanto, una operación UPDATE o DELETE posicionada solo funcionará después de haber realizado primero un FETCH en la misma transacción.

JDBC define los cursores como WITH HOLD por defecto. Esto se hace porque JDBC activa la opción de auto-commit por defecto. Debido a la sobrecarga habitual relacionada con el auto-commit y los cursores WITH HOLD, ambos deberían estar explícitamente desactivados en el nivel de conexión.

Sentencias Update/Delete posicionadas

[editar]

Los cursores no solo pueden ser utilizados para extraer información de la base de datos a una aplicación, sino que también sirven para identificar una fila a modificar o borrar en una tabla. El estándar SQL:2003 define para tal fin las sentencias posicionadas Update y Delete . Estas sentencias no utilizan una cláusula WHERE normal (con predicados de condición). En cambio, el cursor identifica la fila, para lo cual debe ser abierto y posicionado en la misma utilizando la sentencia FETCH . 

 UPDATE table_name
 SET   ...
 WHERE  CURRENT OF cursor_name

 DELETE
 FROM   table_name
 WHERE  CURRENT OF cursor_name

El cursor debe operar sobre un set de resultados que sea modificable para que una sentencia posicionada UPDATE o DELETE pueda ejecutarse con éxito. En caso contrario, el SGBD no sabría como aplicar los cambios en los datos a las tablas subyacentes referidas en el cursor.

Cursores en transacciones distribuidas

[editar]

Usar cursores en transacciones distribuidas (entornos X/open XA), que son controladas utilizando un monitor de transacciones, no es diferente que usar cursores en transacciones no distribuidas.

Aun así, se debe prestar atención al usar cursores WITH HOLD. Las conexiones pueden ser usadas por diferentes aplicaciones. Por lo tanto, una vez una transacción ha sido confirmada y ha terminado, una transacción subsecuente (que fuera de otra aplicación) podría heredar cursores WITH HOLD ya existentes. Este es un punto que los programadores de aplicaciones deben tener en cuenta.

Desventajas de los cursores

[editar]

La siguiente información puede variar dependiendo del sistemas gestores de bases de datos.

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 búfer local y recupera las filas desde el mismo hasta que el búfer 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 solo a una degradación del rendimiento, sino también a fallos más graves.

Referencias

[editar]

Véase también

[editar]