Diferencia entre revisiones de «Cursor (base de datos)»

Contenido eliminado Contenido añadido
Pipepupo (discusión · contribs.)
Pipepupo (discusión · contribs.)
Línea 81:
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 [[Round-trip delay time|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 [[bufferbúfer de datos|bufferbúfer]] local y recupera las filas desde el mismo hasta que el bufferbú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 sólo a una degradación del rendimiento, sino también a fallos más graves.