Newsgroup: it.comp.lang.delphi
Titolo: Query e Velocità

Esiste un modo per velocizzare le query? Ho notato che quando un database
contiene enormi quantità di dati (nel mio caso oltre 10.000 records) ci
mette troppo.
Ad esempio un  semplice select senza condizioni è lenta se paragonata alla
semplice apertura di una ttable.
Grazie Marco

 ha scritto nel messaggio
news:8rf01g$a32$1...@fe2.cs.interbusiness.it...


 se abbinate a Indici.
Mi spieghi cosa vuol dire l'affermazione qui sopra? Non sono molto pratico
di sql. Non capisco cosa intendi quando dici di abbinare le condizioni agli
indici.


...


| > Per ultimo USA le condizioni : ritornano meno records e sono velocissime
| > se abbinate a Indici.
|
| Mi spieghi cosa vuol dire l'affermazione qui sopra? Non sono molto pratico
| di sql. Non capisco cosa intendi quando dici di abbinare le condizioni
agli
| indici.
se posso ti rispondo io,
penso che intendesse di usare un where e di controllare la query
limitandone il numero di record, un RDMS non ha problemi ad _archiviare_
grandissimi mole di dati, ma "crolla" tutto se gli fai una
query che te ne restituisce 10.000 (??) in una botta sola!
Se hai una tabella con... che ne so, gli indirizzi
dei clienti, non c'e' ragione di fare un select * e all'utente
fargli vedere tutto in una enorme dbgrid,
ma mettigli qualcosa di ragionevole nel where,
e... boom, in un attimo hai la risposta ;)
Penso cmq che questa sia la "limitazione" piu' grande per
un RDMS rispetto ad una tabella locale, io uso interbase ma credo sia una
regola fissa,
qualcuno ne sa piu' di me? (ovviamente si'... :) )
Ciao,
Alan Solo

regola fissa,
direi che e' una regola che non esiste.
p.s.
con il termine RDBMS si indica un generico sistema di gestione
di database di tipo relazionale, in questo termine rientrano quindi
anche le tabelle native di BDE che tu chiami "tabelle locali".
si puo' dire che BDE e' un RDBMS esattamente come interbase,
la differenza e' che interbase adotta un'architettura client server
mentre BDE/Paradox usa un'architettura file server.

 specificando espressamente il completo caricamento in locale dei dati.
prova, anche senza cached updates o altro e poi fammi sapere..
ah, magari anche in rete...
vorrei tanto crederti ma non e' cosi', se sbaglio qualcosa dimmelo.
nella mailing list di IB si e' discusso molto su questo,
soprattutto su "select * e TDBGrid"
ripeto, non so se e' un problema di IB, ma non credo
Ciao,
Alan Solo

> le tabelle native di BDE che tu chiami "tabelle locali".
e' l'help di Delphi (e non solamente) che le chiama Local Tables...

ripeto, non so se e' un problema di IB, ma non credo
con MSSqlServer 7 / Win2000 / D5e sicuramente non succede.
p.s.
per massima sicurezza ho provato a generare 30.000 righe in una
tabella paradox, la query SQL "select * from tabella" e' assolutamente
istantanea (in locale, ma non credo cambi molto in rete, e se cosi'
fosse non sarebbe un problema di SQL).

 (proprio in rete)...
si', non mi sono spiegato bene, la risposta e' istantanea anche con IB
indipendentemente dal numero di record "selectati" (bleagh :P), il
problema sorge se all'utente viene l'idea (giusta tra l'altro
altrimenti cosa fa? ;) di scorrere la dbrid con i miliardi di record
che gli abbiamo presentato (magari facendo un last),
a quel punto puo' andarsi a bere un caffe' tranquillamente.
Questo succede con IB, tu che usi MSSqlServer mi interesserebbe molto
sapere se cio' e' uguale o invece viene implementato in modo migliore.
In pratica, se fai un last, vengono fatchati tutti i record,
poi una volta fetchati in locale va che e' una scheggia, pero'...
Da parte del programmatore poi metodi come Locate (RecordCount e filter)
sono assolutamente vietati, in quanto anch'essi forzano un fetch-all
in quanto lavorano in locale, con Tquery standard,
con l' FIBDataset cio' migliora ma non si puo' certo gridare al miracolo
(vengono fetchati tutti i record fino al primo record che soddisfa la
richiesta di ricerca)
FETCHATI, scusami volevo solo dirlo un'altra volta ...:))
Ciao,
Alan Solo

 Alan Solo
Allora, scusate se mi intrometto, ma utilizzare degli RDBMS c/s e voler fare
il browse del dataset è assurdo perché i "tradizionali" Sql Servers basano
la loro esistenza sui "cursori" e non sui record... questo approccio dà agli
utenti la possibilità di avere informazioni giungenti da più tabelle
presentate come un unico "result set". Il problema è che ogni "record" delle
tabelle contiene un offset da cui ricavare quello successivo, ma non quello
precedente. Quindi lo scorrimento può solo essere in avanti e non indietro
di UNO. Cercare di fare operazioni come First e Last porta alla necessità di
scaricare in locale TUTTI i record della tabella ed il BDE si occupa di
quanto sopra una volta che ha a disposizione tutti i dati. Spero di aver
portato qualche spunto alla discussione e di non aver detto troppe
cavolate... ( SQL non è il mio campo... )
Andrea

 campo... )
si e' quello che ho detto (piu' o meno) io, ovvero che un RDMS c/s
(vedi IB, MSQL...) e una tabella Paradox sono due concetti diversi,
per cio' io ho consigliato di ridurre il numero di record ritornati.
Anch'io non sono esperto, ma penso che tu abia ragione, un RDMS lavora
su cursori, mentre Paradox e simili utilizza degli indici i quali hanno 
una perfetta corrispondenza tra record e record successivo/precedente.
Con IB ad esempio questo non succede,se faccio un select * from tabella,
mi vengono ritornati immediatamente i primi n record (dove n sono il numero di
righe della visibili della dbgrid), se si scrolla la griglia uno ad uno
va bene, ma se pero' l'utente vuole andare alla fine,
vengono fetchati tutti i record, per questo ho detto che e' una
grossa limitazione rispetto ad una "semplice" tabella paradox.
Questo succede anche avendo fatto i dovuti indici, e cio' mi porta a
dire, ma allora a cosa cakkio servono gli indici? Mi interessa sapere
se cio' e' una regola fissa o succede solo con IB.
Non vorrei semplificare troppo le cose ma non penso sia difficile
fare un motore sql che se tu ad esempio fai un last ti restituisca
sempre e solo i record che stai viisualizzando e che ti servono,
ovvero, nel caso del last:
l'ultimo, l'ultimo -1, l'ultimo-2, ... l'ultimo -n...
IB e' anche open source ma non ho voglio di andarmi a smazzare il codice
C e vedere come cacchio implementa ste cose, anche perche' non sono
sicuro che il problema sia del motore stesso, ma forse anche degli
oggetti vcl..
Ho provato che l'IBconsole, ma essendo anch'essa scritta in delphi
non cambia nulla, e' sempre lento su tabella di grosse dimensioni.
Spero che qualcuno mi chiarisca le idee, cmq io sono del parere
che, quando possibile si debba impedire all'utente di fare grossi
select senza motivo..
Alan Solo

Per dovere di cronaca, visto che sono stato tirato in ballo, devo dire
alcune cose.
I miei test li faccio sempre sul almeno 700.000.
Ora, non contesto che se scrivo select * from tabella su 30.000 records la
risposta sia immediata per il buffering etc etc.
Ma se gia' scrivo select * from tabella order by qualchecampo penso che hai
gia' un rallentamento.
Se invece di 30.000 sono 700.000 il tempo è naturalmente + lungo per un
fatto squisitamente matematico.
Ora vorrei che qualcuno mi dimostrasse che se ho 10 client in rete collegati
ad un server e da tutti e 10 lancio una bella query select * from tabella
order by qualchecampo nella quale tabella vi sono 700.000 records non vi
sono rallentamenti senza contare il sovraccarico della rete.
Inoltre, a che mi serve far leggere ad un utente 700.000 records quando
magari lui desidera solo un record in partcolare?
Qualcuno userebbe un motore di ricerca che appena accedi alla sua home page
ti mostra
700.000 siti di cui non ci frega niente?
Infatti, esce una bella maschera nella quale si chiede una chiave in base
alla quale si esegue la ricerca.
Infine, il fatto che un sistema sia in grado di reggere grossi carichi di
lavoro non è una buona ragione per sovraccaricarlo 24hx365gg.
Saluti
AS
"Se è Microsoft non funziona"

 in partcolare?
Concordo pienamente.
Ciao,
Alan Solo

 ha scritto:

stavo gironzolando per la borland, e sembra che anche il futuro dbExpress
(probabilemnte in delphi 6 e kylix) seguira' questa filosofia:
"[...]Opening table through BDE not only consumes client resources but
also locks up server resources. dbExpress eliminates the concept of
opening tables, and clients are recommended to use SQL queries
with better selectivity for optimized data-access.[...]"
Ciao,
Alan Solo

lavoro non è una buona ragione per sovraccaricarlo 24hx365gg.
su questo siamo assolutamente d'accordo.

FETCHATI, scusami volevo solo dirlo un'altra volta ...:))
nessun problema :-)

 migliorare le cose, appena ho un po di tempo ci provo...
reqestlive? cosa centra? non vorrei dire cacchiate ma serve solo per
renderti un dataset modificabile "al volo", non penso cambi qualcosa...
Ciao,
Alan Solo

renderti un dataset modificabile "al volo", non penso cambi qualcosa...
si ma implicitamente vuol dire che il cursore non lavora su
una copia del dataset ma direttamente sulla tabella,
puo' darsi che come effetto collaterale produca un cursore
in grado di vedere ancora gli indici e quindi di posizionarsi
rapidamente al fondo alla tabella.