linux user group brescia

>
>
>Secondo me e' errato pensare di dare al server un parametro; per quanto mi risulta il tutto dovrebbe procedere secondo questo schema
>
>1) il client assembla una query fatta e finita, in particolare sostituisce il valore attuale a _tutti_ i parametri formali e ottiene una stringa ASCII contenente uno statement SQL valido
>
>2) il client invia lo statement al server
>
>3) il server elabora lo statement, costruisce il result set e lo rispedisce indietro
>
>4) il client legge il result set.
>
>Tutte le operazioni di selezione, proiezione e join vengono svolte sul server (come e' giusto che sia). Quello che transita in rete e' 
>
>*) la stringa contenete la query sql
>*) il result set _finale_ cioe' solo i dati che compongono il tuo risultato (e non e' detto che siano _tutti_ i record, vedi cursori). 
>
>  
>
Più o meno sì, ma di solito un database esegue una query in due fasi che 
si possono da programma possono essere eseguite sia insieme che 
separatamente: prepare ed execute. Il vantaggio nel tenere questi passi 
separati è che in fase di prepare si possono lasciare dei parametri da 
indicare poi in fase di execute, ed in questa maniera gran parte del 
lavoro fatto dal DB (join, proiezione, magari parte della selezione) 
viene eseguito solo la prima volta.
Per esempio (scopiazzato, scusate per eventuali errori), in perl:
------------------------
$q=$db->prepare("select nome, targa from utenti, auto where 
auto.proprietario=utenti.nome and utenti.codice= ?");
$q->execute("1323");
...
$q->execute("1453");
...
------------------------
equivale a:
------------------------
$q=$db->prepare("select nome, targa from utenti, auto where 
auto.proprietario=utenti.nome and utenti.codice= 1323");
$q->execute();
...
$q=$db->prepare("select nome, targa from utenti, auto where 
auto.proprietario=utenti.nome and utenti.codice= 1453");
$q->execute();
...
------------------------
(tra l'altro ora che lo guardo, forse è proprio quello che cercava 
cartolina).
Comunque, a seconda dell' implementazione del DB e della query 
utilizzata, la prima versione può essere molto più veloce, ricordo una 
volta con Oracle 7.3, client VB ed una query incasinatissima in cui la 
prepare durava circa 20 volte la execute, un caso con SQL server 6 non 
ha dato grossi cambiamenti, probabilmente il server o gli ODBC tenevano 
una cache delle ultime prepare eseguite.
N.B. una query di cui hai fatto la prepare ti succhia delle risorse sul 
DB, non puoi aprirne troppe contemporanamente,e bisogna ricordarsi di 
chiuderle a fine lavoro.

>>sto leggendo di cursori, ma o non e' quel che cerco o non ho capito bene
>>l'uso che ne posso fare.
>>    
>>
>
>Un cursore e' un modo per leggere il result set un record per volta, in maniera sequenziale o random. Da come ho capito io il tuo result set dovrebbe essere composto di una unica tupla, quindi aprire un cursore e' inutile; tuttavia in alcuni linguaggi (es java) i result set si possono interrogare solo usando un cursore. Se il linguaggio che usi ti da la possibilita' di ottenere direttamente l'intero result set con uno statement unico, fregatene dei cursori.
>
>  
>
L'accesso a DB avviene comunque tramite cursori, tranne che li gestisce 
la libreria; tipicamente lo statement unico fa
- prepare
- execute
- accesso tramite cursore
- chiusura della query

Resta la cosa più comoda quando non hai problemi di prestazioni.

Ciao
Marcello