Newsgroup: it.comp.lang.delphi
Titolo: Domanda per espertissimi sui database

Ho un programma scritto in delphi 3 che utilizza degli archivi paradox
collegati su di un server di rete...
Questo programma funziona in maniera abbastanza regolare e fluida, ma quando
ho convertito il programma in delphi 4, il programma diventa lentissimo, ci
mette anche 3 minuti per effettuare una ricerca, visualizzare una tabella e
per fare qualsiasi altra operazione sugli archivi...
Credo di aver individuato il problema, ma non ne sono certo, e vorrei il
parere di una persona esperta, potrebbero essere dei campi nei miei archivi
che sono di tipo lookup, cioč che prendono alcuni campi da altre tabelle, vi
risulta che esista un problema del genere???
Sarebbe davvero importante per me risolvere questo tipo di problema.
Grazie.

 che sono di tipo lookup, cioè che prendono alcuni campi da altre tabelle,


ma se il campo in questione ti serve su n tabelle,
il tuo trigger deve aggiornare n tabelle.
Se inserimenti e modifiche sono poco frequenti la cosa
potrebbe andare, fermo restando una grossa violazione
delle regole di normalizzazione.
Ma se sono frequenti e gli archivi sono belli tosti....
Sicuro che una join non vada altrettanto bene?
Bye
AS
"Se è Microsoft non funziona"
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:a0511b5958cdc2e277...@mygate.mailgate.org...


Non posso risolverlo con una join, mi troverei a dover leggere e scrivere il
campo in un altra tabella, ed oggetti come i dbgrid mi permettono di
leggerne
solo una per volta...


Sicuro che una join non vada altrettanto bene?
Piano con il consigliare le JOIN.
Se i dati crescono, diventano la peggiore delle pesti.
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]

Se i dati crescono, diventano la peggiore delle pesti.
Assolutamente falso, se le join utilizzano degli indici.
-----------
Ore 18.30: premo invio.

 Assolutamente falso, se le join utilizzano degli indici.
Assolutamente vero, per il modo in cui le JOIN normalmente
sono eseguite.


sono eseguite.
Possiamo andare avanti tutto il giorno, se vuoi, a dire assolutamente
vero, assolutamente falso, ho ragione io, no ho ragione io.
Ha degli argomenti, o stai facendo, come spesso ami fare, il bastian
contrario? 
Posso postarti chili di "execution plan" se hai tempo da perdere.


 Posso postarti chili di "execution plan" se hai tempo da perdere.
No, non ce l'ho purtroppo...


No, non ce l'ho purtroppo...
Non ne dubitavo :-P
-- 
Ore 18.30: premo invio.

 vediamo se dopo un po' il BDE rimane ancora lucido.
Non esiste solo paradox.
Come tu hai + volte sottolineato, paradox è un pochino un caso
a se:
conviene il TTable
non conviene usare le join
etc
Mai fatto test con le join su Oracle o Sybase?
Bye
AS
"Se è Microsoft non funziona"
-- 


 etc
Beh, io starei attento a consigliare le TTable a chiunque e con qualunque
DB. Sono il top dell'inefficenza. Se i dati crescono e devi fare un pò di
operazioni non banali, cominci a creare un I/O su disco (non prendo neanche
in considerazione DB condivisi in rete) mostruoso. Le prestazioni vanno
dietro di conseguenza. A morte le TTable. Viva le TQuery.
G.

Forse non hai letto i post precedenti.


 Bye
I post precedenti li ho letti.
E comunqe l'affermazione "conviene il TTable" almeno che non fosse detta in
senso ironico, continua a farmi storcere il naso.
G.



Forse non hai letto molto bene.Alberto ha scritto:
*******************se:*************************
conviene il TTable
non conviene usare le join
-- 
Ore 18.30: premo invio.

 Mai fatto test con le join su Oracle o Sybase?
Non sto parlando ne' di Oracle, ne' di Sybase.
Il discorso oggettivo e' che la costruzione di una JOIN, 
in generale, e' un'operazione molto pesante.


 DB. Sono il top dell'inefficenza. 
Falso almeno con Paradox.  Le TTable vanno bene per gestire
discrete moli di dati con questo DB (ho visto lavorare le TTable 
con centinaia di migliaia di record senza dare alcun problema).
La natura di Paradox, d'altronde, implica che le TTable non gestiscano
milioni di record, perche' esso stesso ha difficolta' a farlo.
Con Paradox si puo' lavorare in tre modi diversi:
1. Usando una TTable (sfruttando i metodi del TDataSet);
2. Usando una TQuery (sfruttando i metodi del TDataSet);
3. Usando una TQuery e statement SQL;
Il primo punto e' quello da me preferito.
Il secondo e' perfettamente intercambiabile con il primo,
ma alla fine e' il TDataSet a uniformare le cose.
Il terzo punto e' assolutamente sconsigliabile, lento e
difficile da gestire.


 wrote in message
news:XfJsPFmpDK0qNT...@4ax.com...

Nonoavevo letto bene...
sorry. ;o)

 difficile da gestire.
Beh, un pò + difficile delle TTable, ammetto, che sono la prima cosa che
tutti usano quando cominciano a familiarizzare con Delphi. Come sono la
prima cosa che uno cerca di abbandonare quando il gioco comincia a farsi
serio.
Ciao,
G.

 abbandonare quando il gioco comincia a farsi serio.
Io con Delphi non gioco e per applicazioni serie in cui Paradox
e' il DB sottostante, si e' utilizzato le TTable senza alcun 
(e sottolineo *alcun*) problema.
Se poi vuoi continuare a credere che siano la peste, senza
averle mai utilizzate per cose serie, allora fai pure.


in generale, e' un'operazione molto pesante.
Ma questi dati *oggettivi* saresti anche cosě gentile da
giustificarli?


 averle mai utilizzate per cose serie, allora fai pure.
Aaaaah! Potevi dirlo prima! Non sapevo di parlare con un VERO professionista
che usa anche DB che non sono Paradox.
G.

 giustificarli?
Non ho nessun dato oggettivo da mostrarti, se con questo
intendi grafici o spiegazioni su fogli lucidi, la giustificazione
deriva direttamente dall'esperienza: le join sono notoriamente
operazioni molto pesanti e lente.


 VERO professionista che usa anche DB che non sono Paradox.
Sei sicuro di aver capito tutto quello che e' stato detto ?
Oltre a Paradox, utilizzo Interbase, ma non vedo che cosa 
c'entri questo con quanto stiamo dicendo.  Ho detto che Paradox 
l'ho utilizzato e lo utilizzo anche per progetti che tu chiami
*seri* e non mi ha dato mai problemi.
