Newsgroup: it.comp.lang.visual-basic
Titolo: vb.net: datagrid con 350.000 record ......che fare?

Ciao 
ho la necessità di visualizzare un elenco di circa 350.000 record
in un datagrid.
Le prestazioni dell'applicazione sono molto lente.
qualcuno di voi mi sa aiutare a trovare qualcosa che migliori le 
prestazioni? grazie tante Alessandra.

 ha scritto nel messaggio 
news:200504281...@mynewsgate.net...


 in un datagrid.
Sei sicura di avere questa necessita'???
Chi quell'umano che può leggere, facilmente, 350.000 righe???
Credo che tu stia sbagliando approccio al problema...
-- 
Gianluca Cannalire
Microsoft MVP/MCP - Visual Basic
http://www.visual-basic.it
http://community.visual-basic.it/gianluca

 
sono d'accordo con Gianluca.
Se il dg e' usato per un utente probabilmente e' opportuno effettuare un 
filtraggio dei dati in modo da mostrargli solo quelli effettivamente 
cercati.

 ha scritto:

Ciao,
molto lento a caricarmi la maschera con la griglia che raccoglie
un elenco di 350.000 clienti, per poterne selezionare uno tra i tanti.
Il mio data base è Sql Server. Ho creato una funzione che mi estrae
i dati dal database e tramite Vb effettuo l'accesso richiamando la 
function di SQl.
anche questa function è pesante, ci impiega 16 secondi ad estrarmi i dati
poichè è una join tra 3 tabelle!!!

 ha scritto

in attesa dei suoi, saggi, ne provo io uno, ruspante.
dato che 350k righe non se le scorrerà mai nessuno, proponi direttamente una
ricerca, in cui individuare il nominativo in base a cognome e/o nome e/o età
e/o residenza e/o quelcheè.
tipo:
select where cognome like 'ratzing% and nome like 'jose%' and eta > 60 and
residenza='c.d.v.'
poi nei 350k ci guardi tu con una query e all'utente proponi la selezione
nella griglia. i papabili saranno molti meno e il concl, ehm l'utente potrà
sceglierne uno :)
ciao, a.

 residenza='c.d.v.'
senza andare a scomodare i santi, e visto che effettivamente è impossibile
effettuare una ricerca "a mano" in centinaia di migliaia di item, potrebbe
limitarsi a raccogliere i primi, chessò, 100 clienti in ordine alfabetico,
tanto per accontentare l'occhio...
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 clienti in ordine alfabetico, tanto per accontentare l'occhio...
E che criterio sarebbe? :)))
Quanto esposto da Andrea č l'unica soluzione: filtrare i dati in base ad 
uno o piů criteri di ricerca combinabili tra di loro per ridurre (anche a 
qualche centinaio) il resulset dei nomi.
Far visualizzare il primi 100, in ordine alfabetico, su un set di 350.000 
records non ha, IMHO, assolutamente alcun senso...
Ciao!


Potresti proporre sotto l'elenco una serie di label da A a Z in modo da 
dare una prima scrematura, nel senso che se clicco su A vengono 
visualizzati solo qulli che iniziano per A e cosi' via
Andrea Palazzi ha scritto:


 records non ha, IMHO, assolutamente alcun senso...
epperò hai il vantaggio di sapere, a priori, a prescindere dalla
numerosità dell'elenco di partenza, che avrai a che fare con un numero di
elementi che non ti impalla la macchina.
Anzi... dirò di più.
potrebbe tranquillamente far vedere sempre i primi 100 item frutto della
ricerca, informando l'utente che sono molti di più, e che gli conviene
introdurre qualche altro parametro se non vuole impazzire nella ricerca
manuale.
naturalmente, imho...



C'è qualcosa di sbagliato nell'approccio con cui tu hai affrontato il
problema, perché 16 (sedici) secondi per SQL Server sono davvero un
tempo eterno. Non è che ti carichi tutti i 350.000 clienti in un
dataset?
--
Ciao!
Luca Menegotto

qualche centinaio) il resulset dei nomi.
Con la differenza che puoi ricorrere alla paginazione, e nel ricorrere
alla paginazione puoi fare affidamento a una ben disegnata stored
procedure di SQL Server, il quale è li proprio per fare questo; perché
allora far fare il lavoro al client? C'è un articolo molto
interessante su DevLeap proprio sull'argomento:
http://www.devleap.com/SchedaArticolo.aspx?IdArticolo=10690
D'altra parte, ricorda sempre con quanta velocità Google ti fa vedere
una piccola selezione di qualche milione di records... :)))
--
Ciao!
Luca Menegotto

 una piccola selezione di qualche milione di records... :)))
Beh, hai idea di quanti server ci sono dietro a google? :)
Comunque, resto dell'idea che l'utente deve lavorare poter con il minor 
numero di dati (record) utili.
La paginazione risolve solamente il problema "visivo" ma non quello 
concettuale di restituire decine (se non centinaia) di migliaia di record 
all'utente finale.


 Beh, hai idea di quanti server ci sono dietro a google? :)
stavo per dire "prova a cercare 'google cluster'", poi ci ho provato
direttamente:
http://www.computer.org/micro/mi2003/m2022.pdf
dove si vede che non è solo questione di hw. l'hw conta, ma contano anche
gli algoritmi e la strutturazione dell'insieme. anche in un semplice db se
crei un indice su *ogni* parola chiave di un memo e la ricerca la fai
sull'indice vai piu' veloce anche in ado, rispetto al where memofield like
'%abc%'...
comunque, se la query l'hai fatta male, non è la paginazione che ti salva.
noise in, noise out: vale ancora. ottieni molto rumore ben paginato.
bisogna che chi fa la ricerca e chi gliela vuole far fare si chiariscano un
attimo le idee. cosa vogliono ottenere, ciascuno dal suo punto di vista? nei
termini esposti, una normale query su campi brevi sembra la soluzione piu'
efficiente.
ciao, a.

 '%abc%'...
esempio:
http://www.nist.gov/dads/HTML/invertedIndex.html

all'utente finale.
Io credo dipenda dall'applicazione. Se è un gestionale, probabilmente
hai ragione. Io però ho avuto necessità qualche volta di smazzarmi un
log di un firewall per comprendere alcune anomalie che mi erano state
segnalate. Ho dato un range di una decina di minuti.... hai idea di
quanti records siano venuti fuori? :))))
In questo caso, la paginazione sarebbe andata benissimo, anche se il
client implementava una cosa del tipo DataGrid OLEDB.
--
Ciao!
Luca Menegotto

noise in, noise out: vale ancora. ottieni molto rumore ben paginato.
Oddio, io la sapevo "garbage in, garbage out". Il concetto però non
cambia, son d'accordo con te.
--
Ciao!
Luca Menegotto

>'%abc%'..
D'altra parte, se il filtro where memofield like '%abc%'..
e' sitematico e frequente allora il db designer e' meglio
che cambi mestiere ;-)
-- 
ciao, hal

 concentrarsi sul server, che č li che non fa nulla... ;-)
Quoto ed aggiungo: il motore del server e' fatto *apposta*
per questi lavori. I vari Sort, Find ecc. di ADO & Co. hanno
senso su dataset di piccole dimensioni e/o creati in memoria.
Su grandi quantita' di dati una bella stringa sql e' piu' facile
da gestire, richiede meno codice, e' piu' flessibile e piu'
potente di qualsiasi soluzione locale.
Facciamo fare al database il suo mestiere ed al visual basic
di turno il suo. Se si puo' usare un martello invece del
tacco di una scarpa per piantare un chiodo...
-- 
ciao, hal

 client implementava una cosa del tipo DataGrid OLEDB.
No, continuo a non essere d'accordo... Anch'io spesso ho da analizzare log 
corposi (in particolare, quelli di IIS) ed è inutile (a parte rarissime 
eccezioni) leggerli riga per riga. Tanto per cominciare, c'è sempre un 
modo per 'limare' il resulset: analizzare i log di un firewall in un range 
di una decina di minuti, puo' restituire diverse migliaia di records... ma 
se li stai analizzando, vuol dire che sei alla ricerca di qualche cosa in 
particolare. Quindi, potrai ancora ridurre il risultato limitando i record 
che provengono o che sono indirizzati ad un certo IP, oppure che 
utilizzano una particolare porta anzichè un particolare protocollo. E' 
vero che a volte il linguaggio SQL puo' risultare 'limitato' per 
particolare operazioni di raffinamento della ricerca... Ma in tal caso, le 
regular expression ti permettono di colmare questa mancanza.


 tacco di una scarpa per piantare un chiodo...
Allora, invece che "una bella stringa SQL", vediamo di scrivere qualche 
stored procedure in piů, che č meglio... molto meglio ;)
ciao!


particolare. 
Non necessariamente. A me č successo di avere una mezza idea, ma di
non sapere *esattamente* cosa stavo cercando. L'ho ben capito solo
quando ho ultimato l'analisi. E in questa situazione si fa una fatica
bestiale a limitare l'interrogazione.
--
Ciao!
Luca Menegotto


Ho solo un dubbio. non si va fuori standard ANSI? Boh, mo me lo leggo
bene...
--
Ciao!
Luca Menegotto

 stored procedure in più, che è meglio... molto meglio ;)
Mica ho detto dove scriverla ;-)
-- 
ciao, hal

 Crescita zero.
ah, si chiama così, crescita zero, non frz itl ? beh, in effetti torna...
:))

 che cambi mestiere ;-)
necessito input. spiegare, prego.

 :))
:-DDD
-- 
ciao, hal

 necessito input. spiegare, prego.
lo hai gia' spiegato tu descrivendo come lavora google ;-)
-- 
ciao, hal

 ha scritto

ah, capito. per archiviare i miei messaggini di posta mi servono 15ooo pc e
una sofisticata struttura di shards e inverted indexes. così non mi toccherà
piu' fare where testo like '%google%' and to='hal1961' per trovare questo
messaggio :P

 messaggio :P
visto che ci siamo intesi al volo? ;-PPP
-- 
ciao, hal

 visto che ci siamo intesi al volo? ;-PPP
si vede, eh, che siamo due uccelli ? :P

 :))
LOL
Peccato che ci ho messo un tot a capirla :-(
Vai di caffeina, vai...
Bye, G.

 Mica ho detto dove scriverla ;-)
Ok, te la passo per buona ;)


 Ok, te la passo per buona ;)
Per un attimo hai rischiato di essere inondato
da km di codice pl/sql :-P
-- 
ciao, hal

 da km di codice pl/sql :-P
Sia mai!!! :)
Mi basta quello che scrivo per conto mio ;)
