title: Cursor (base de datos)
text: # 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
  
  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.
  
  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.
  
  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.
  
  El último paso consiste en cerrar el cursor utilizando la sentencia CLOSE.
  
  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
  
  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.
  
  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.
  
  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
  
  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.
  
  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
  
  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 .
  
  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
  
  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
  
  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.
  
  