Newsgroup: it.comp.www.asp
Titolo: Pezzi e bocconi di recordset.

Ho gia' postato su it.comp.software.database e nessuno mi filato, vediamo se
sono piu' fortunato qui!:-)
Il server http passa una select al server dati, questo gli rimanda un
malloppone che il serve http pagina prima di spedirne al client una sola
piccola porzione. Ovviamente tutto il recordset e' transitato sulla lan.
C'e' un modo, o forse un escamotage, per far si che solo n righe siano
spedite al server http?
Diciamo qualcosa tipo LIMIT ma con preventivo posizionamento del cursore al
record x.
Mi riferisco a MySQL.
Saluti.
Luciano

 ha scritto nel messaggio
news:a23b9p$u4f05$1...@ID-86073.news.dfncis.de...

Ovvio, dovevi postare prima qui......;-)
Il propblema della paginazione è un classico ma non credo ci sia una
risposta *universale*.
A WPC ho cercato confronti con guru del mondo db (SQL server), e quello che
ne è uscito è la stessa conclusione a cui sei arrivato tu.
Ovvero, evitare il + possibile di far viaggiare dati tra db server e http
server.
Il paging di ADO invece fa proprio questo!!!
Il problema è come ottenere lo scopo.
In SQL server ti direi una stored procedure, in mySQL ....boh.
In ogni caso:
Soluzione A
SELECT     TOP <elementi x pagina><campi>
FROM         <tabella>
WHERE     (Chiave > <primo o ultimoValore Precedente>)
ORDER BY Chiave [DESC nel caso di pagina precedente]
La prima soluzione è quella di passare l' ultimo (o il primo) valore su cui
il tuo recordset è ordinato (in ASCENDING o DESCENDING, e rifare la query
per > di quel valore con una clausola TOP n ove n è il numero di
record-pagina.
Ovviamente molto meglio se il criterio di ordinamento è la chiave primaria o
un campo comunque indicizzato e UNIQUE.
In caso contrario la query rallenta pesantemente (in funzione del numero di
record nella tabella) dovendo probabilmente ricorrere ad un table scan.
Inoltre, se l'ordinamento non è per chiave univoca, la tua pagina può
contenere un numero maggiore di record (a parità dell' ultimo valore, la TOP
preleva tutti i record corrispondenti).
E in questo caso, non puoi nemmeno gestire a mano il ritorno di n record,
perchè potresti perderti dei record quando la pagina termina tra due record
con valore di ricerca uguale.
E non è finita.
Se nel frattempo un'altra transazione ti elimina qualche record precedente,
ritornando indietro nello scorrimento delle pagine, ti ritroverai la prima
con un numero di record inferiore(di n record quanti sono quelli
cancellati).
Soluzione B
SELECT     TOP <elementi x pagina><campi>
FROM         <tabella>
WHERE     (Chiave <> ALL
                          (SELECT     TOP <quanti ne deve saltare> <campi>
                            FROM          <tabella>
                            ORDER BY Chiave))
ORDER BY Chiave
molte considerazioni sono analoghe e ho qualche perplessità sulle
performance ma è senz'altro + semplice.
L' ho fatta un po' lunga eh ?

 L' ho fatta un po' lunga eh ?
Scherzi? Non mi sembra una questione da liquidare in due righe!:-)
Saluti.
Luciano

 Luciano
Ciao.

 Chi mai se li sfoglia 10 a 10?
Il senso e' dato semplicemente dal risultato. Se hai tanti record e'
possibile che un filtro non scremi molto. E a quel punto devi gestire nel
modo piu' efficiente possibile. Ovvio che nessuno sfoglia a 10 a 10 fino
alla fine,  ma puo' saltare direttamente alla pagina n.
E comunque anche mille record possono essere tanti avanti e indietro su una
lan.....pensa ad esempio se c'e' un campo TEXT.
Grazie comunque, sei stato prezioso!:-)
Saluti.
Luciano