Informazioni sulla scelta di un tipo di cursore
La scelta di un tipo di cursore dipende da numerosi fattori:
Dimensioni del set di risultati.
Percentuale dei dati necessari.
Esecuzione dell'apertura del cursore.
Operazioni del cursore necessarie, ad esempio scorrimento e aggiornamenti posizionati.
Livello di visibilità delle modifiche apportate ai dati da altri utenti.
I valori predefiniti sono accettabili per set di risultati di piccole dimensioni se non viene eseguito alcun aggiornamento. Per i set di risultati di dimensioni maggiori, è consigliabile utilizzare un cursore dinamico che consente all'utente di ottenere più facilmente una risposta prima di recuperare un numero di righe elevato.
Se i dati da recuperare verranno utilizzati tutti simultaneamente e non sono necessari aggiornamenti posizionati o scorrimento, è consigliabile utilizzare i set di risultati predefiniti. In SQL Server è stata rimossa la restrizione che impedisce di avere più set di risultati predefiniti in attesa, se si utilizza MARS (Multiple Active Result Set).
Regole per la scelta del tipo di cursore
Per la scelta di un cursore è necessario rispettare alcune semplici regole:
Se possibile, utilizzare i set di risultati predefiniti. Se è necessario utilizzare lo scorrimento, è più efficiente inserire nella cache del client un set di risultati di piccole dimensioni e scorrere la cache anziché richiedere al server di implementare un cursore.
Utilizzare i valori predefiniti per il recupero di un intero set di risultati nel client, ad esempio per generare un report. I set di risultati predefiniti rappresentano il metodo più veloce per la trasmissione di dati al client.
Non è possibile utilizzare i set di risultati predefiniti se nell'applicazione sono in uso gli aggiornamenti posizionati.
È necessario utilizzare i set di risultati predefiniti per istruzioni Transact-SQL o batch di istruzioni Transact-SQL che generano set di risultati multipli.
I cursori dinamici vengono aperti più velocemente rispetto ai cursori statici o gestiti da keyset. Quando vengono aperti cursori statici e gestiti da keyset è necessario creare tabelle di lavoro temporanee, che invece non sono necessarie per i cursori dinamici.
Nei join, i cursori statici e gestiti da keyset possono risultare più veloci dei cursori dinamici.
Se si desidera eseguire operazioni di recupero assolute, è necessario utilizzare cursori statici o gestiti da keyset.
I cursori statici o gestiti da keyset comportano l'utilizzo di una maggiore quantità di spazio del database tempdb. I cursori del server statici vengono creati interamente in tempdb, mentre i cursori gestiti da keyset generano solo il keyset in tempdb.
Se un cursore deve rimanere aperto durante un'operazione di rollback, utilizzare un cursore statico sincrono e impostare CURSOR_CLOSE_ON_COMMIT su OFF.
Quando si utilizzano i cursori del server, ogni chiamata a una funzione o a un metodo di recupero API provoca un round trip al server. Nelle applicazioni è necessario che il numero di tali round trip venga ridotto al minimo tramite l'utilizzo di cursori a blocchi che restituiscono un numero di righe sufficientemente elevato per ogni operazione di recupero.