Newsgroup: it.comp.lang.delphi
Titolo: QUERY (Join) e Campi di lookup

Salve a tutti.
Ho un problema con le query. Utilizzo il BDE, non chiedetemi di passare al
altro perche adesso non lo posso fare.
Ho creato una griglia db evoluta che permette di ordinarne il contenuto
cliccando sulle intestazioni. A questo scopo ho utilizzato una query o
comunque un dataset derivato da una query. Fino a qui tutto ok. Ho notato
poi che ordinare i dati per un campo di lookup non era possibile, infatti un
campo per essere  ordinato deve fare parte delle stesso dataset (ho
sbaglio?).
Allora ho utilizzato gli Join su tabelle, ma ho notato una lentezza
spaventosa quando si chiude e si riapre un dataset cosi ottenuto. Per
esempio eseguendo una query con lookup su 4000 record ci impiega circa 5
sec. invece utlizzando una join ce ne vogliono 13.
Qualcuno mi sa dire come posso ovviare a tale problema? C'è un altro modo
per ottenere un dataset composto senza utilizzare una join?
Grazie Marco

 modo per ottenere un dataset composto senza utilizzare una join?
penso di no
Ciao,
Alan Solo


8-o 
Ma io faccio join da 100.000 in su ? Sbaglio ? A forse sono sbagliati
i database, certo i limiti di 2miliardi record sono virtuali, grazie
se non ci fossi tu.....
Massimo
----------------------------------------------------------
Il vero problema non č tanto sapere se le macchine pensano
bensě se gli uomini pensano. B.F. SKINNER (1904-90)
----------------------------------------------------------

 non ci fossi tu.....
:D
guarda, avevo deciso di ignorarti ma non ho resito
questo e' il post che ha fatto trabboccare il vaso
SEI PROPRIO UN COGLIONE.

vaffanculo, un paio di mesi fa ero contento, ma veramente contento
di aver trovato un posto dove sentitmi "a casa" (forse l'unico),
grazie, grazie mille di cuore
comunque,
...in sostanza, ho riscritto per dirti, perpiacere, di *non* *rispondere*
e *non* *fare* *battute* idiote perche' io non sto scherzando,
e' solo il mio ultimo sfogo, se mi e' permesso
rivaffanculo
e
addio.
[chiedo scusa per i due post, ma sono gli ultimi]

SEI PROPRIO UN COGLIONE.
EHEHEHEHEH ma la mamma lo sa' che dici le parolacce ? Vabbe' se sei
buono ti do' un lecca-lecca. 
Massimo
----------------------------------------------------------
Il vero problema non č tanto sapere se le macchine pensano
bensě se gli uomini pensano. B.F. Skinner (1904-90)
----------------------------------------------------------


Ma tutte queste parolacce chi te le insegna ? Forse a scuola ? Te l'ho
detto di non frequentare certa gente....
Massimo
----------------------------------------------------------
Il vero problema non č tanto sapere se le macchine pensano
bensě se gli uomini pensano. B.F. Skinner (1904-90)
----------------------------------------------------------

 se non ci fossi tu.....
E magari spedisci il result con una dll ISAPI su una pagina html ad un
povero cristo sulla rete che aspetta due giorni per vedere il risultato ....

Ma io faccio join da 100.000 in su
con paradox ?


Facciamo a capirci, la colpa non puň essere del numero di record,
eventualmente l'utente va' avvertito con un msgbox che la richesta da
lui effettuata prendera' parecchio tempo, scusa ma allora Oracle che
lo hanno inventato a fare ?
Non vedo l'utilita' di un RDBMS che porta milioni di record e poi non
puoi estrarne piu' di .... 500, ho lavorato con Oracle e DB2
manipolavamo milioni di record e facefavo stampe di nnn pagine,
nessuno si č mai lamentato.




Perche' mai due giorni ?
Il tutto dipende da che DBMS usi per il fetching dei dati.
Ci sono DBMS che trattano moli di dati ingenti in un baleno.
Abituiamoci a pensare che, per fortuna, nel mondo esistono DBMS seri
(non solo Access e Paradox).
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia
"ci sono tre tipi di persone nel mondo : quelli che
 sono bravi in matematica e quelli che non lo sono."

- *non* fare una select con 4000 record!!! ;)
Certo, bella soluzione.
E' come dire a uno che ha una cancrena alla gamba di non tagliarsela
perche' l'operazione e' troppo lunga.
Per fortuna al mondo ci sono DBMS in grado di sopportare query su
4.000.000 di record !


per ottenere un dataset composto senza utilizzare una join?
Il problema e' capire se ti serve davvero una join.
Le join sono le operazioni piu' costose in termini di efficienza e
piu' ingombranti in termini di risultati.
Puoi fare un esempio piu' preciso ?


 termini di risultati. Puoi fare un esempio piu' preciso ?
l'ha gia' fatto, vuole ordinare una tabella su di un campo di lookup,
non vedo altre soluzioni
... oppure "rompere le regole" e le relazioni tra le tabelle
es.
da una cosa del tipo
tabella1(id1, id2, campi_di_1...)
tabella2(id2, campo2)
ad una
tabella( id1, campo1, campo2)
a volte bisogna sacrificare spazio su disco e le regole di
normalizzazione per avere piu' velocita'
Ciao,
Alan Solo

 (non solo Access e Paradox).
specialmente con i motori SQL e' sempre consigliabile avere una maggior
selezione dei dati, ovviamente, quando possiblie
Ciao,
Alan Solo

 4.000.000 di record !
"*non* fare una *select* con 4000 record!!!"
intendevo, ma ovviamente tu e il tuo amico non avete capito,
non fare una select che ti restituisce 4.000 record in una botta sola
(poi chissenefrega se il DB ne contiene 4 gigabilioni...)
con 4.000 record utilizzando un TDataset di BDE (che probabilmente se
li fetcha tutti al client) puoi avere anche un mostro sacro come Oracle
sotto, la cosa non cambia, o meglio, cambia, ma non ti aspettare miracoli
Ciao,
Alan Solo

per ottenere un dataset composto senza utilizzare una join?
puoi duplicare il campo di ordinamento sulla tabella da ordinare...

non fare una select che ti restituisce 4.000 record in una botta sola
Non ne vedo il perche'.


non vedo altre soluzioni
C'e' sempre un'altra soluzione.
Scusami, ma non ho abbastanza fiducia in cio' che affermi.


 Non ne vedo il perche'.
essenzialmete perche' un server sql lavora con cursori, e poi anche il
traffico di rete (e non)  ...
(cmq ne abbiamo gia' discusso, per me puo' finire qui...)
Ciao,
Alan Solo

 cio' che affermi.
ragiona, il server sql neanche sa' della esistenza dei campi di lookup
presenti nell'oggetto TQuery/TTable del programma, quindi l'unico modo
e' far fare una join *AL* motore SQL stesso e fare un order by su quel
campo...
ripeto io *NON VEDO* (vuoi che scriva sempre cosi'?...) altre soluzioni,
se qualcuno ha altre soluzioni, ben venga...
cmq e' una soluzione accettabilissima con un motore SQL, visto che Carlo
Bosich conferma che e' un problema solo di Paradox (io non l'ho mai
usato)
Ciao,
Alan Solo