Newsgroup: it.comp.lang.delphi
Titolo: Per non utilizzare reccount

quando eseguo una ricerca in un archivio tramite una select ... like
posso avere un dataset vuoto e con isempty verifico la condizione lancio un messaggio che non è stata trovata nessuna corrispondenza e finisce lì.
in alternativa potrei avere un record o più come posso gestire la il tutto senza utilizzare reccount?
Grazie Brunello


I fatti dicono che reccount diventa pericolosa quando hai tanti, 
tantissimi record: tuttavia, quando parlo di "tanti, tantissimi record" 
in un contesto come quello attuale, con cpu multicores,giga di ram 
montate su ogni pc, reti ethernet da 1 gigabits, è come non dire niente 
o tutto perchè troppi sono i fattori che influenzano la risposta di una 
select: architettura, carico/throughput e topologia della rete, il 
database, CPU multicores, ram, ecc..
 
Di recente avevo fatto un benchmark interessante con firebird database 
caricando tutta la divina commedia in una tabella priva di indici e 
lanciando una ricerca full text avevo ottenuto, sorprendentemente, una 
risposta velocissima: 
http://tiny.cc/firebird_full_text_test
 
 
Questo per dirti che si va da caso a caso: fai qualche prova 
sperimentale, colleziona un pò di dati e verifica se davvero il 
recordcount ti blocca un client oppure è solo un errore di valutazione.
Nel caso fosse bloccante lo elimini con una query preventiva che conta 
gli effettivi record.
 
Un'altra cosa che mi viene in mente è il tipo di database: ormai la 
ricerca full text è recepita da tutti i principali database engines, 
quindi ti conviene mettere un indice ben studiato sul campo in cui 
andrai a fare la ricerca e fare un pò di benchmarking per vedere i 
risultati.
 
 
 
-- 
morde
Android
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
 

 
Il fatto che "va bene nel x% dei casi" per me equivale ad un "non va bene".
In base all'unica vera fede (la legge di Murphy), un giorno o l'altro capitera' che la recordcount finisce per lavorare su un dataset con troppi records.
Ergo: RECORDCOUNT NON ESISTE.
 
Personalmente, uso una count preventiva.
E se il numero di record supera un limite (ovviamente, ma non per tutti, configurabile a livello di singola worsktation e per singola griglia), l'utente si vede un bel messaggio del tipo "il filtro restituisce un numero di righe eccessivo. Impostare un filtro piu' restrittivo". 
Il messaggio include quanti record restituisce la query e quale ' il valore limite accettato.
 
Mo voi vi chiederete "perche?"..
 
Risposta:
Le griglie devexpress permettono di ordinare, raggruppare etc.
Ma per fare cio, devono ovviamente (ma non per tutti) caricare tutti i record in memoria. 
Quindi, se la query restuisce 400.000 records mentre la griglia si carica tutto in memoria faccio in tempo ad andare a Napoli a mangiare una pizza fritta.
 
A.

grazie per la risposta è mi conferma quello che avevo subodorato, l'unico problema è che i dati a cui accedo sono solo in lettura e non posso alterare il db creando indici. 
ciao Brunello

> In base all'unica vera fede (la legge di Murphy), un giorno o l'altro capitera' che la recordcount finisce per lavorare su un dataset con troppi records.
 
il problema nasce dalla like.
Se un utonto immette una stupidissima 'A' come ricerca all'interno dei nominativi dell'anagrafica di un comune come quello di Milano apriti cielo. Nel mio caso l'archivio e' molto piu' ristretto pero' il pericolo e' latente, per questo avevo chiesto il suggerimento di approccio diverso, sicuramente seguiro' la strada della count preventiva, grazie dei suggerimenti.