Newsgroup: it.comp.lang.delphi
Titolo: Velocità SQL

Ho un dubbio...
Se devo effettuare delle modifiche su alcuni record di una tabella č piů
performante utilizzare un oggetto TTABLE con i relativi metodi .Insert
.Edit... oppure utilizzare un oggetto TQUERY col metoto .ExecSQL (con UPDATE
SQL)?
Io sono quasi sicuro che č piů veloce il secondo metodo... ma ho conosciuto
oggi qualcuno che afferma il contrario!!
Grazie a tutti.



E come lo ha giutificato?
Da una parte devi aprire una tabella, ricevere un live dataset, utilizzare dei
cursori dinamici e bookmarks e, una volta modificata la tabella fare il post
(che se visti a basso livello, sul lato server, sono, guarda caso, degli update
e degli insert).
Dall'altra fai solo il post.
Massimo.
-- 
"Ciao Rex, che cavolo di situazione eh? Due dentro, due fuori, puo' succedere di tutto!"

 ha scritto nel messaggio
news:uDpxOwmbifd8g+...@4ax.com...


 Io sono quasi sicuro che è più veloce il secondo metodo... ma ho


 ha scritto nel messaggio
news:hXdc7.31$JY1....@news.infostrada.it...


 ma ho conosciuto oggi qualcuno che afferma il contrario!!
fammelo conoscere anche a me, e poi vedi quanto sono veoloce io a
dargli bacchettate sulle mani... ;-)))
Ciao,
Alan Solo

un'istruzione SQL?
Non credo.
Tieni presente che SQL e' un linguaggio nato per gli utenti
finali, non per i programmatori, quindi non c'e' motivo di
usarlo per funzioni di basso livello (in realta', gli stessi
programmatori ne abusano, a volte).
Credo che, a basso livello, il BDE si affidi al driver
nativo specifico (questo puo' far si' che le TTable siano, a
volte, piu' veloci delle TQuery).
Non ho ben ragionato su questa cosa, fa molto caldo a casa
mia, e puo' darsi stia dicendo una stupidaggine.
In ogni caso, indubbiamente il testo di una query deve
essere prima "parsato" dal server SQL e questo, benche'
porti via una frazione di secondo con i moderni server, e'
comunque un fattore che rallenta.
Con un UPDATE non vai direttamente sul recordo interessato
(a basso livello), nel senso che il server DBMS deve
"comunque" usare un indice per recuperare il record (se c'e'
una clausola WHERE su un campo indicizzato) nel migliore dei
casi e scorrere la tabella nel peggiore.
Attendo correzioni.
--
Naquern Yansbetevn
naquern.y...@africamail.com

volte, piu' veloci delle TQuery).
come sopra, penso che se si sta parlando di server SLQ il driver si
occupa solo di passare le istruzioni SQL al server...
Ciao,
Alan Solo

utilizzando Connection, Command e Recordset.
non usare quella roba (VB) ti fa male ;-)
vedi che non stai ragionando da Delphista ma da VBista, per usarlo via
codice basta che ti crei gli oggetti... vi a codice!!!
var Db TDatabase;
Db := TDatabase.Create;
Db. Alias := 'pippo';
Db.connected := true;
Db.ecc
Db.ecc
Db.ecc
ps: gli oggetti *sono* codice
;-)
Ciao,
Alan Solo

perchè tu come fai? perchè abusarne?
Quando parlo di lavorare a basso livello mi riferisco al
BDE.  Con SQL e' molto facile combinare dei grossi pasticci,
che vengono fuori quando si abusa di esso.
--
Naquern Yansbetevn
naquern.y...@africamail.com

che vengono fuori quando si abusa di esso.
non sono d'accordo, meglio usare SQL che funziona sempre e "parla"
direttamente al server SQL... non vedo che casini si possano fare...
ps: anche BDE, assieme a TTable è morto... ;-)
dbExpress lavora tutto su query SQL... 
Ciao,
Alan Sol

client
Be', una "SELECT * FROM TABELLA" non e' da meno.
In ogni caso, ho fatto delle prove di inserimento di 100.000
record in tabelle vuote (cognome e nome).
I benchmark li prendo sempre con le molle, pero' la
differenza di tempo in operazioni singole tra i metodi del
TDataset e gli statement SQL, mi sembrano eclatanti.  
Una TTable ha compiuto 100.000 inserimenti in 12 secondi e
mezzo, circa (9,67 Mb).  La TQuery (un semplice statement
INSERT) l'ho dovuta bloccare per noia.
Ho notato, invece, che la copia speculare della tabella
piena (con un INSERT FROM TABELLA1 SELECT * FROM TABELLA2)
l'ha compiuta in circa 2 secondi.
Secondo me, per operazioni eseguite di continuo (esempio,
delle insert successive eseguite molto di frequente), l'uso
delle TQuery (proprio perche' implicano il processamento di
SQL) rallenta parecchio le operazioni.
Non credo che TTable tramuti le sue operazioni in statement
SQL.
--
Naquern Yansbetevn
naquern.y...@africamail.com

dbExpress lavora tutto su query SQL... 
BDE e' morto ed e' bene che sia cosi'.
La morte di TTable mi lascia indifferente.
Ma il fatto che dbExpress utilizzi solo query SQL non vuol
dire che sia il modo piu' veloce di operare.
Delphi puo' interfacciare AS/400 con dei componenti nativi,
cosi' come la stessa Oracle ha prodotto dei componenti per
l'accesso diretto alle proprie basi dati.
Il paradigma SQL viene usato per comodita', non perche' sia
il mezzo piu' veloce.
--
Naquern Yansbetevn
naquern.y...@africamail.com

 >E poi alla fine il lavoro fatto da Ttable (a basso livello) non č sempre


> TTable)
In effetti sono stato un po' troppo affrettato. Ho letto database e la mia
testolina ha pensato client-server!
In effetti, con sistemi come Paradox le chiamate dirette sono sicuramente piů
veloci di TQuery che vengono interpretate.
Mea culpa.


 Io sono quasi sicuro che è più veloce il secondo metodo... ma ho


usare.
Usa solo TQuery
Ciao
--
Piero Bonanno
bop...@libero.it
pie...@tiscalinet.it
bpie...@hotmail.com
______________________________________________
"Madame, lei ha tra le gambe uno strumento
che puo' offrire piacere a migliaia di persone,
e tutto quello che sa fare e' grattarlo"
- Sir Thomas Beechan a una violoncellista

: TTable, TQuery????
Visto che TTable non sara' piu' supportato, ti conviene
utilizzare TQuery.
--
Naquern Yansbetevn
naquern.y...@africamail.com

cosa, la sua resa dipende da come viene utilizzato!
E' esattamente cio' che ho detto.
--
Naquern Yansbetevn
naquern.y...@africamail.com

Paradox con RDBMS come SQL Server ed Oracle!
.. anche secondo me non possono essere paragonati, io sinceramente ho
usato solo RDMS nella mia vita (specialmente IB/FireBird) e la stessa
Borland consiglia il passaggio da Paradox ad un RDMS, anche perchè non
ci sarà mai un supporto in dbExpress per paradox & company...
ps: DB2 *è* un RDMS
Ciao,
Alan Solo

codice basta che ti crei gli oggetti... vi a codice!!!
In realta' non e' vero che VB faccia a meno degli oggetti. 
Trattandosi di ADO, deve far riferimento comunque a degli
oggetti COM, anche se per il programmatore e' trasparente.
--
Naquern Yansbetevn
naquern.y...@africamail.com

SQL) rallenta parecchio le operazioni.
si, in quel caso conviene scriversi delle stored procedure *nel* RDMS
e non rieseguire ogni volta una query, che come dici tu se viene
ripetuta molte volte rallenta molto...
Ciao,
Alan Solo

SQL)?
riposto al thread originale che ci è sfuggito di mano,
vuoi fare degli update?
usa TQuery:
UPDATE tabella
SET Campo = valore
WHERE altrocampo= altrovalore
con TTable dovresti fare:
Table.Open
usare locate (pesantissssimo) o un cilco per cercare il record che ti
serve
Table.Edit
Table.fieldbyname('campo').AsQualcosa := valore;
Table.Post;
alla fine, ho realizzato anche io che abbiamo fatto un casino in
questo thread... ma se si usa un RDMS è meglio, + veloce, + standard,
+ecc.. usare TQuery (punto e basta) 8)
Ciao,
Alan Solo

probabilemente ottieni gli stessi risutati che con TTable
Chiaro, ma non e' cio' che voglio fare, perche' cosi'
tornerei ad utilizzare i metodi del TDataset.
E quindi, nel caso il TDataset faccia riferimento alle API
di basso livello del driver, non userei piu' SQL.
Sul discorso delle stored procedure : vero nel caso dei
DBMS, in caso di Paradox e database file-based in generale,
c'e' poco da fare.
--
Naquern Yansbetevn
naquern.y...@africamail.com

oggetti COM, anche se per il programmatore e' trasparente.
infatti probabilmente sono oggetti anche in VB esattamente come in
Delphi... ho solo spiegato che lo si puo' fare via codice benissimo
anche da Delphi, il l'unica cosa che cambia è che invece di prendere
l'oggetto non visuale (TDatabase, TQuery, ecc..) dalla palette lo si
crea semplicemente a runtime via codice... ;-)
un programamtore Delphi (o OO a caso) lo avrebbe intuito che tutti gli
oggetti li si possono creare anche ad codice e non solo a
design-time...
Ciao,
Alan Solo

+ecc.. usare TQuery (punto e basta) 8)
Secondo me quando si usa un RDBMS e' meglio utilizzare cio'
che e' studiato per QUEL RDBMS.
Se poi non rimane altro che SQL, pazienza.
Ricordiamoci che la S di SQL sta per "Structured", non
"Standard", ed e' un dato di fatto che oggi ogni RDBMS serio
implementa estensioni proprie di questo linguaggio, tali da
rendere ogni query piu' o meno complessa incompatibile con
tutti gli altri.
--
Naquern Yansbetevn
naquern.y...@africamail.com

Delphi...
Preciso che gli ADO prescindono dai linguaggi.
Sono oggetti esterni alle applicazioni.
--
Naquern Yansbetevn
naquern.y...@africamail.com

un "select *", anche se ti serve un solo record....
Se vogliamo fare un confronto tra TTable e TQuery dobbiamo
farlo nei termini giusti.  Sei sicuro che con SetRange, la
Open della Table corrisponda a un fetch all ?
--
Naquern Yansbetevn
naquern.y...@africamail.com

c'e' poco da fare.
già....
Ciao,
Alan Solo

gestita attraverso una query SQL... 
Investighero' meglio su questi aspetti di basso livello ma
non credo proprio sia come dici.  Ripeto, SQL non e'
progettato perche' sia un layer di basso livello.
Dubito molto che un metodo Insert di un TTable si traduca in
uno statemente SQL.
--
Naquern Yansbetevn
naquern.y...@africamail.com

Open della Table corrisponda a un fetch all ?
grrr, no capisco perchè ti ostini a difendere TTable ;-)
scusa, non ho Delphi/Help/niente sottomano, SetRange cosa dovrebbe
fare, limitare il numero di record ritornati? Quindi che so metti 10 e
ti ritorna solo i primi 10(provo ad indovianre)? e se quelli che ti
servono sono 11? come fai a saperlo a priori??
Ciao,
Alan Solo

tutti gli altri.
dipende da come la si vede, io preferisco, specialmente per quanto
riguarda i dati usare qualcosa di estremamente standard
ps: IB, ad es, *č* serio, ed č uno dei + aderenti allo standard in
assoluto...
Ciao,
Alan SOlo

ti ritorna solo i primi 10(provo ad indovianre)? 
No, imposti il range in base a un criterio.
--
Naquern Yansbetevn
naquern.y...@africamail.com

facilmente convertibile
Ripeto : se per standard intendi il linguaggio SQL, ci sono
troppi casi in cui di standard c'e' veramente poco.
E' un'utopia quella che vuole che le query progettate per un
RDBMS siano facilmente trasportabili sotto altri RDBMS.
Provaci e poi mi fai sapere.
--
Naquern Yansbetevn
naquern.y...@africamail.com

 delle prestazioni.
Posso garantirti che le mie tabelle (ben strutturate e relazionate!)
contengono un numero di record discretamente alto... prova ad immaginare il
traffico che compiono 14 Milioni di clienti Omnitel che parlano
quotidianamente al telefono... vogliamo fare un benchmark delle mie
performance?
Comunque ho dedotto quanto dovevo.
Resto solido sulla mia opinione e proseguirò per la vecchia (ma buona)
strada!!
Prometto che vi seguirò simulando un caloroso pubblico laddove voi vogliate
continuare.
Non posso comunque fare a meno che ringraziarvi della partecipazione...
davvero molto calorosi.
Al prossimo thread!
Ciao.
Giuseppe Vitali
Omnitel Pronto Italia s.p.a.

Al prossimo thread!
ok! ;-)
Ciao,
Alan Solo