Ok. L'idea è questa: qual'è il modo più veloce per create una tabella NUMBERS (NUMBER int) con dentro un milione di numeri che vanno da 0 a 999999? Tutto ovviamente nel TempDb e con anche la DROP della tabella appena creata nel più sano spirito di querettaro da strapazzo!

Già è molto divertente pensare a diversi modi, sempre più veloci, ... Io sono riuscito a passare da minuti ad un secondo netto. E mi raccomando, il tutto deve essere provato su un Notebook ciofeca come il mio, possibilmente con Sql Server Express per stare in regola. Insomma non è una gara di hardware ma di come si scrive meglio le query.

Vi allego lo script, vale la pena di provarlo, un pezzo alla volta e con le statistiche client attive. Ci sono dentro dei trucchi notevoli, come quello con il GO 1000000, e arrivano anche delle delusioni grosse, come quella delle IDENTITY che non c'è modo per farle andare forti. 

Sul mio ferro si passa da minuti, a qualche secondo e nell'ultima versione ad un secondo netto, davvero niente male, chi rova il tutto su un qualche server un pelo decente? fatemi sapere i tempi!

Vi consiglio di scaricare lo script e nel frattempo seguire questo breve commento:

Prova 0: solo per vedere il GO 1000000 che ripete un comando un milione di volte. non provatela senza la transazione altrimenti fate notte. Ma se fossi in voi non la lancerei neanche (ma se lo fate, visto che la interromperete a metà, ricordatevi di rollbeccare e droppare la tabella).

Prova 1: un classico ciclo, la prima grossa delusione perchè non va, da dimenticare subito

Prova 2: il prodotto cartesiano. mentre fino ad ora erano scherzi, ora si incomincia ad ottenere un qualche tempo accettabile. Attenzione il prodotto cartesiano da la paga a tutti i precedenti metodi 'da programmatore'!

Prova 3: Prodotto cartesiano con select into, una conferma che la select into è molto più veloce della insert select

Prova 4: Altra grossa delusione la IDENTITY non va manco a spingerla

Prova 5: Il massimo con query compatibili SS2000

Prova 6: Le common table expression sono una bomba

Prova 7: Versione finale! voi riuscite a fare di più?

Oggi mi viene una idea: vediamo chi su google usa il mio nickname: bellagita. Ok per ora sono solo io.

Però così facendo scopro che grazie alliscrizione allo ugiss ho un mio spazio blog da anni e che non ho mai usato.

Allora incomincio con o scrivere na cosetta per Sql Server che è stata na figata: ho implementato una classe che eredita da Stream per leggere da un blob di Sql Server. Ma vi raccoto la storia: volevo ridurre il numero di file temporanei del mio applicativo: un sistema di stampa basato su active report. I layout di stampa sono dei file xml, anche grandi, e che tengo zippati dentro ad un campo di SqlServer. Per leggerli dovevo estrarre lo zip, primo file, scompattarlo, secondo file, e caricarlo. Ok non era poi lentissimo, ma nenache esaltante. Tutte le classi che uso supportano gli stream, tranne l' SqlDataReader che però ha dei metodi per leggere a blocchi.

Ma guarda un po' questi metodi sono proprio quello che ci vuole per fare uno stream: detto fatto, ho una classe che implementa uno stream n sola lettura da Sql Server.

Risultato: apro il data reader (con il flag xxx che adesso non mi ricordo) lo passo al mio stream, che passo allo stream di dezip che lo do in pasto ad activereport che legge, flush del tutto e chiusura del tutto. Il codice è calato di dimensioni, i buffer usati sono molto più piccoli, nessun file temporaneo, tutto è ok, tutto è veloce e fantastico!

Bisognerebbe fare una cosa del genere (uno stream) anche in scrittura, non è impossibile anzi, ma è più complicato perchè bisogna scrivere dei comandi sql per pompare su i dati, che semplicemente richiedono una valanga in più di nformazioni. Un'altra volta.

 Ok, non è un argomento da blob, stavo postando un articolo sull' ugiss ma l'avevo appena finto quando è saltata la corrente (!!!!). Adesso è passato un mese.

Penso che nessuno leggere questo mio blog (si vede dalla sintassi, molto sciolta), l'articolo sarebbe stato meglio, ma ... è andata così.