Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Una curiosità sul metodo FIll

0 views
Skip to first unread message

Andrea

unread,
Jun 11, 2006, 5:52:25 PM6/11/06
to
Il terzo costruttore per la precisione, quello dove specifichi un numero
di indice di paternza e
il numero di record da recuperare.

Andrea, tu in particolare, credo mi possa rispondere visto che hai scritto
pure su aspitalia di
questo, solo hce non menzioni nulla in merito.

Il mio dilemma è, ma quel metodo, riesce veramente a paginare senza scaricarsi
mezzo database?
Oppure se lo scarica tutto e poi pagina?
Ho provato ad andare a vedere con il reflector, ma tra la chiamata di un
metodo e l'altro
mi sono veramente perso.

Ciao
ANdrea

Raffaele Rialdi [MVP]

unread,
Jun 12, 2006, 2:43:02 AM6/12/06
to
> Il mio dilemma è, ma quel metodo, riesce veramente a paginare senza
> scaricarsi mezzo database?

No

> Oppure se lo scarica tutto e poi pagina?

Usa un datareader, quindi la query viene eseguita nel suo globale (il che
obbliga il db ha creare il resultset completo) e poi salta i record che non
rientrano nell'intervallo specificato.


--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://blogs.ugidotnet.org/raffaele

Andrea

unread,
Jun 12, 2006, 6:20:43 AM6/12/06
to
>> Il mio dilemma è, ma quel metodo, riesce veramente a paginare senza
>> scaricarsi mezzo database?
>>
> No

Grazie della orrenda risposta :)

Ciao
Andrea

Raffaele Rialdi [MVP]

unread,
Jun 12, 2006, 7:04:07 AM6/12/06
to

Prego :)

Il fatto è che la paginazione è prima di ogni altra cosa una questione di DB
e non di provider.
E anche sul db non può esistere una soluzione efficente *e* universale. Se
vuoi la paginazione, è meglio progettare fin dall'inizio le tabelle in modo
che sia possibile farlo umanamente ;-)

Cristiano Larghi

unread,
Jun 12, 2006, 7:17:26 AM6/12/06
to
In data Mon, 12 Jun 2006 13:04:07 +0200, Raffaele Rialdi [MVP] ha scritto:

> Il fatto è che la paginazione è prima di ogni altra cosa una questione di DB
> e non di provider.
> E anche sul db non può esistere una soluzione efficente *e* universale. Se
> vuoi la paginazione, è meglio progettare fin dall'inizio le tabelle in modo
> che sia possibile farlo umanamente ;-)

...oppure usare mysql che ha un bel "limit" ... :-/

"The LIMIT clause can be used to constrain the number of rows returned by
the SELECT statement. LIMIT takes one or two numeric arguments, which must
both be non-negative integer constants (except when using prepared
statements).

With two arguments, the first argument specifies the offset of the first
row to return, and the second specifies the maximum number of rows to
return. The offset of the initial row is 0 (not 1):

SELECT * FROM tbl LIMIT 5,10; # Retrieve rows 6-15

To retrieve all rows from a certain offset up to the end of the result set,
you can use some large number for the second parameter. This statement
retrieves all rows from the 96th row to the last:

SELECT * FROM tbl LIMIT 95,18446744073709551615;

With one argument, the value specifies the number of rows to return from
the beginning of the result set:

SELECT * FROM tbl LIMIT 5; # Retrieve first 5 rows

In other words, LIMIT row_count is equivalent to LIMIT 0, row_count. "

--
"That until there is no longer first class
And second class citizens of any nation
Until the colour of a man's skin
Is of no more significance than the colour of his eyes
Me say war"

B.M.

Andrea

unread,
Jun 12, 2006, 7:55:40 AM6/12/06
to
> Il fatto è che la paginazione è prima di ogni altra cosa una questione
> di DB

Si si lo so, solo che ero arrivato ad un punto che purtroppo quel caxxo di
access
con tutte le join che ho fatto per scovare il record corretto, appena mettevo
un
filtro del tipo where descrizione = o like qualchecoas, schiattava inesorabilmente.

E la query, mi schiattava proprio perchè usavo un meccanisco di 3 sottoselect
annidate
per fargli fare la paginazione, ma evidentemente ho chiesto troppo !!!

Vabbè :(

Appena passo questo progetto a sql server, sicuramente dimagrisco di 10 kg,
quelli
che sto prendendo di incazzature varie.

Ciao
Andrea

Andrea

unread,
Jun 12, 2006, 7:56:08 AM6/12/06
to
> ...oppure usare mysql che ha un bel "limit" ... :-/
>
> "The LIMIT clause can be used to constrain the number of rows returned
> by the SELECT statement. LIMIT takes one or two numeric arguments,
> which must both be non-negative integer constants (except when using
> prepared statements).

Tanto è che nemmeno la 2005 ci sono riusciti ad infilarcela dentro ... e io
che speravo :=)))

Ciao
Andrea

David

unread,
Jun 12, 2006, 8:01:04 AM6/12/06
to
Cristiano Larghi ha scritto:

> ...oppure usare mysql che ha un bel "limit" ... :-/

E al quale mancano tante belle cose... comunque IMHO anche con mysql e la
clausola limit il result set č calcolato per intero e poi ritornati al
client solo i record interessati.

Credo che Raffaele con "Se vuoi la paginazione, č meglio progettare fin

dall'inizio le tabelle in modo che sia possibile farlo umanamente"

intendesse tutt'altra cosa.


Andrea

unread,
Jun 12, 2006, 8:39:03 AM6/12/06
to
> Cristiano Larghi ha scritto:
>
>> ...oppure usare mysql che ha un bel "limit" ... :-/
>>
> E al quale mancano tante belle cose... comunque IMHO anche con mysql e
> la clausola limit il result set è calcolato per intero e poi ritornati

> al client solo i record interessati.

Ed è giusto quello che manca ad access o sql server, dove per inciso, un
qualsiasi sistema di pagina preveda nel caso più banale una stored procedure
che internamente prenda un tot di risultati appartenenti al tuo criterio
di ricerca
e te li rispedisce indietro.

Così come sta, access, ti spara giù anche 1GB di datase (ammesos che non ti
schiatti prima access) e poi ti fa fare la paginazione.
Sql server, ti spara giù il tuo resultset completo a meno che non lo filtri
prima tu.

MySql e la clausola limit invece, fanno quello che farebbe una buona stored
procedure
in sql server, ti danno già il trancio di risultaot che ti occorre, ma questo
non
significa aver fatto tutto quello che occorre per la paginazione.
Hai bisongo ancora di un recorcount con il quale costruire il numero navigatore
delle
pagine, e un pagerecordcountindex al quale aggiungerai + 1 per far recuperare
la
query del risultato della pagina successiva o un - x dove x è il tuo numero
di record
per pagina per tornare indietro di 1 o n pagine.

Ciao
Andrea

Andrea

unread,
Jun 12, 2006, 8:39:43 AM6/12/06
to
> vuoi la paginazione, č meglio progettare fin dall'inizio le tabelle in

> modo che sia possibile farlo umanamente ;-)

Non per farti svelare segreti industriali :) ma cosa implica la tua tecnica
di progettazione?

Ciao
Andrea

Raffaele Rialdi [MVP]

unread,
Jun 12, 2006, 10:20:20 AM6/12/06
to
>> E anche sul db non puň esistere una soluzione efficente *e*
>> universale. Se vuoi la paginazione, č meglio progettare fin

>> dall'inizio le tabelle in modo che sia possibile farlo umanamente ;-)
> ...oppure usare mysql che ha un bel "limit" ... :-/
>
> "The LIMIT clause can be used to constrain the number of rows
> returned by the SELECT statement. LIMIT takes one or two numeric
> arguments, which must both be non-negative integer constants (except
> when using prepared statements).

La conosco ma dubito della sua efficacia rispetto ad una paginazione fatta
con una query ad hoc.
Prendi la cosa con le molle perché non conosco come sia implementata nč mi
sono mai dedicato a farci sopra qualche test di performance.

In sostanza quello che temo č che l'engine di mysql costruisca comunque il
resultset completo ma che poi limiti le righe ritornate a quelle indicate
dalla clausola LIMIT.
Se cosě fosse ci sarebbe veramente poca differenza con la Fill del
dataadapter.

Il vero guadagno in performance lo puoi avere se il resultset estratto dalla
query č piccolo, non se questo viene filtrato successivamente.

Ad ogni modo rimanderei questa discussione a chi ne sa di piů nel ng di sql.

Raffaele Rialdi [MVP]

unread,
Jun 12, 2006, 10:25:11 AM6/12/06
to
Andrea wrote:
>> vuoi la paginazione, è meglio progettare fin dall'inizio le tabelle

>> in modo che sia possibile farlo umanamente ;-)
>
> Non per farti svelare segreti industriali :) ma cosa implica la tua
> tecnica di progettazione?

Purtroppo dipende di caso in caso, altrimenti ci sarebbe un sistema generico
e probabilmente sarebbe già implementato dentro i db engine.
Il discorso che facevo è quello, in sostanza, di filtrare il resultset a
pagine con la where. Devi quindi avere una colonna che ti permetta di
identificare degli intervalli di righe e recuperarne un po' alla volta. Il
tutto deve tenere conto che nel frattempo le righe possono aumentare o
diminuire per effetto dell'attività degli altri utenti.

Se la paginazione è fatta con la where il resultset è più piccolo e il db
lavora in modo più efficiente. Ovviamente se hai tabelle con mille record,
tanto vale usare quella Fill e basta.

David

unread,
Jun 12, 2006, 11:18:19 AM6/12/06
to
Raffaele Rialdi [MVP] ha scritto:
> In sostanza quello che temo è che l'engine di mysql costruisca comunque il
> resultset completo ma che poi limiti le righe ritornate a quelle indicate
> dalla clausola LIMIT.

Potrebbe fare altrimenti visto che posso giocare a mio piacere con la order
by? IMHO se non ha un risultato completo non riesce a paginare in sessun
modo.

> Se così fosse ci sarebbe veramente poca differenza con la Fill del
> dataadapter.

Quoto!


Andrea

unread,
Jun 12, 2006, 12:15:08 PM6/12/06
to
> Il discorso che facevo č quello, in sostanza, di filtrare il resultset

> a
> pagine con la where.

E' quello che ho fatto ma con 6 tabelle in join e una where, access mi schiatta
sotto
il naso. E' colpa di access e del cliente che non decide di passare a qualcosa
di piů
serio, ma questa č un'altra storia.

Ciao
Andrea

Raffaele Rialdi [MVP]

unread,
Jun 12, 2006, 1:58:59 PM6/12/06
to

beh, ormai con sql express che č gratuito non ci sono piů scuse ;-)

Raffaele Rialdi [MVP]

unread,
Jun 12, 2006, 1:59:16 PM6/12/06
to
David wrote:
> Raffaele Rialdi [MVP] ha scritto:
>> In sostanza quello che temo č che l'engine di mysql costruisca

>> comunque il resultset completo ma che poi limiti le righe ritornate
>> a quelle indicate dalla clausola LIMIT.
>
> Potrebbe fare altrimenti visto che posso giocare a mio piacere con la
> order by? IMHO se non ha un risultato completo non riesce a paginare
> in sessun modo.
>
>> Se cosě fosse ci sarebbe veramente poca differenza con la Fill del
>> dataadapter.
>
> Quoto!

:-)

Alessandro AKA Trinità

unread,
Jun 12, 2006, 2:50:03 PM6/12/06
to

> Tanto è che nemmeno la 2005 ci sono riusciti ad infilarcela dentro ... e io
> che speravo :=)))
>
> Ciao
> Andrea

cmq con la TOP che in sql server è diventata paramentrica, si può fare la
paginazione da db. E forse essendo appunto una "top" lavora meglio che la
limit per i motivi che avete detto

su sql 2000 invece per farla lato db bisogna passare per una tabella
temporanea e metterci dentro un campo autoincrementante. Si può fare ma la
cosa è dispendiosa...

In caso si può pensare ad un cache del dataset, creata in modo opportuno

Andrea

unread,
Jun 13, 2006, 2:49:07 AM6/13/06
to
> Andrea wrote:
>
>>> Il discorso che facevo è quello, in sostanza, di filtrare il

>>> resultset a
>>> pagine con la where.
>> E' quello che ho fatto ma con 6 tabelle in join e una where, access
>> mi schiatta sotto
>> il naso. E' colpa di access e del cliente che non decide di passare a
>> qualcosa di più
>> serio, ma questa è un'altra storia.
> beh, ormai con sql express che è gratuito non ci sono più scuse ;-)
>

No, le scuse ci sono. Gli hoster che non hanno le vie di mezzo :)

Cmq, a valor di cronaca. Il buon Scott ha pubblicato qualcosa che fa al caso
nostro. Sentito parlare di LINQ (non vedo l'ora di una uscita definitiva)
e DLINQ?

http://weblogs.asp.net/scottgu/archive/2006/06/04/Using-DLINQ-with-ASP.NET-_2800_Part-2-of-my-LINQ-series_2900_.aspx

Offre anche un esempio di paginazione, che cmq non differisce da quello attuale,
ovvero tutto il resultset che ti torna indietro. Però introduce due proprietà
StartFrom e Skip che fanno esattamente quello che fa il limit di MySQL. Era
ora.
Speriamo solo che la query che genera sia ottimizzata, ma visti gli stralci
di codice,
sembrerebbe che il LINQ in generale sia proprio il valido sostituto di tutte
le gerarchie
di dataAccess.

Ciao
Andrea

Raffaele Rialdi [MVP]

unread,
Jun 13, 2006, 8:35:56 AM6/13/06
to
> No, le scuse ci sono. Gli hoster che non hanno le vie di mezzo :)

Certi hoster mi stanno sulle scatole :-)

> Cmq, a valor di cronaca. Il buon Scott ha pubblicato qualcosa che fa
> al caso nostro. Sentito parlare di LINQ (non vedo l'ora di una uscita
> definitiva) e DLINQ?

eh eh, ero a Los Angeles alla PDC quando l'hanno presentato.


> Offre anche un esempio di paginazione, che cmq non differisce da
> quello attuale, ovvero tutto il resultset che ti torna indietro. Però
> introduce due proprietà StartFrom e Skip che fanno esattamente quello
> che fa il limit di MySQL. Era ora.

vale tutto quello che abbiamo detto fin'ora nel thread.
Sull' "Era ora" non sono daccordo. Se alla fine il lavoro del db è lo stesso
di quando recuperi tutto il resultset allora non fa alcuna differenza
rispetto alla famosa Fill. Lo stesso vale per la Limit di mysql.


> Speriamo solo che la query che genera sia ottimizzata,

basta che ti guardi le query con il profiler

> ma visti gli
> stralci di codice,
> sembrerebbe che il LINQ in generale sia proprio il valido sostituto
> di tutte le gerarchie
> di dataAccess.

L'ho detto più volte. Secondo me DLinq è un nuovo modo di pensare al DAL e
non è un ORM.
Da questo punto di vista è un ottima cosa.

0 new messages