So che tendiamo ad evitare cursori e loop all'interno di SQL Server ad ogni costo, ma quali sono alcune delle situazioni in cui sono assolutamente necessarie query procedurali e le query basate su set non ti danno i risultati?
Capisco la differenza tra i due, non sono mai arrivato a una situazione in cui ho bisogno di usare un cursore. Mi chiedo se ci siano situazioni del genere.
Risposte:
Nelle mie esperienze, mi sono imbattuto in alcune volte in cui erano giustificati approcci procedurali / iterativi.
Se volevo modificare a livello di codice il tipo di dati da reale a decimale in una tabella che ha 500 colonne mal digitate come questa domanda SO , un cursore è un ottimo approccio in quanto il DDL non consente di modificare più colonne in una singola istruzione.
Se si dispone del libro Deep Dives di SQL Server MVP , il capitolo 4 "Iterazione basata su set: la terza alternativa" di Hugo Kornelis contiene alcuni casi d'uso utili per operazioni combinate basate su cursore / set. Due dei problemi classici a cui fa riferimento l'autore del capitolo sono i totali correnti e l' imballaggio bin .
Ho usato l'approccio di iterazione basata su set con buon successo per un processo mal progettato che ho ereditato nell'ultimo lavoro. In breve, c'era un processo che una volta all'anno doveva aggiornare 50-75 milioni di righe e tentare di farlo in un unico set avrebbe fatto saltare i nostri registri. Raggruppando gli aggiornamenti in lotti più piccoli di N righe, ha permesso al registro di tenere il passo e in realtà è finito più velocemente dell'anno precedente quando hanno appena assegnato una metrica di spazio su disco.
Quando qualcosa non può essere fatto impostato in base.
Sanguinamento ovvio ovviamente. Ma nota che c'è differenza tra "non basato su set" e folk usando una soluzione procedurale perché non capiscono i set o non sanno come farlo con il codice basato sui set.
Un esempio di codice procedurale sarebbe l'invio di un'e-mail per riga con contenuto diverso per riga
Un sacco di codice SQL per l'uso DBA è procedurale. Ad esempio, il looping (CURSOR o WHILE: nessuna differenza) su database e tabelle per ricostruire indici e aggiornare le statistiche.
Alcuni costrutti SQL consentono l'elaborazione riga per riga nel contesto di un set, come CROSS APPLY come questo su SO: SELECT TOP 5 righe per ogni FK (nota anche la soluzione ROW_NUMBER ())
Modifica: estensione della risposta di @ billinkc ...
CROSS APPLY consente operazioni basate su set con UDF con "API a riga singola"
So che stai chiedendo informazioni su SQL Server, ma nel mondo Oracle (in passato), le tabelle temporanee avevano un costo molto elevato, quindi le procedure e i trigger basati su cursore erano più rapidi e "costano" più rapidamente per il server. In SQL Server, i cursori avevano un costo molto più elevato rispetto alle tabelle temporanee, quindi la scrittura di codice basato su cursore era scoraggiata. Sono abbastanza sicuro che queste discrepanze siano state eliminate nell'ultimo decennio.
Per far fronte a queste situazioni, molte persone hanno una regola generale per evitare di inserire la logica aziendale nel database. Se puoi assolutamente farlo sempre, non ci sarà motivo di logica procedurale né in T-SQL né in PL / SQL. I database relazionali sono ottimi per la logica basata su set. La maggior parte dei linguaggi di programmazione moderni sono ottimi nella logica procedurale. È meglio usare ognuno per quello in cui sono bravi.
Alcuni trigger di controllo con cui ho lavorato avevano regole piuttosto complicate per ciò che doveva essere verificato e dove le cose dovevano essere aggiornate / registrate. Alcuni erano per mantenere sincronizzati i sistemi di reporting con i sistemi transazionali (non era una mia scelta, ma lo volevano in quel modo). Alcuni erano per un sistema di formule . Un formulario è un elenco di farmaci e, per ciascuna compagnia assicurativa, ciò che copriranno / non copriranno, e se prescritto farmaco_X quali sostituzioni sono coperte dall'assicurazione. Era anche comune che diverse polizze di gruppo presso la stessa compagnia assicurativa pagassero droghe diverse.