Newsgroup: it.comp.lang.delphi
Titolo: aiuto!!! QUERY INTERBASE

ciao, dovrei cercare di risolvere un problema...
ho le seguenti tabelle...
contatti (ckey)
telefonicontatti (ckey)
indirizzicontatti (ckey)
telefoni e indirizzi sono legati a contatti tramite ckey, dovrei riuscire a
visualizzare una griglia in cui visualizzo SULLA STESSA RIGA tel1,tel2, tel3
(che equivalgono alle prime 3 righe dei telefoni) e indirizzo1, indirizzo2
(che equivalgono alle 2 righe di indirizzi), qualcuno di voi ha un idea???
Simone

heheh se potessi modificare il db allora lo standardizzerei, il problema è
che non lo posso fare, ho persino provato a caricare il db dentro un
dxMemData ma è troppo lento
Simo
"Fabio V." <nos...@ecspam.cxz> ha scritto nel messaggio
news:3H5za.133023$3M4.3...@news1.tin.it...


 ha scritto nel messaggio
news:Gd5za.132843$3M4.3...@news1.tin.it...


 molti record
E' lento perchč i campi vengono ricalcolati ogni volta che ti ci posizioni
sopra!
Il ClienteDataSet invece li calcola solo una volta, potrebbe esserti di
aiuto!
CIAO!


 E' lento perchè i campi vengono ricalcolati ogni volta che ti ci posizioni


questo si chiama cross table.
Non credo esista modo diretto di gestire questa cosa.
Un modo consiste nel creare una tabella temporanea:
CREATE TABLE TMP_CONTATTI(
TMP_ID INTEGER NOT NULL PRIMARY KEY,
TMP_USER VARCHAR(XX) NOT NULL,
CONTATTI_CAMPO1 VARCHAR(XX),
CONTATTI_CAMPO2 VARCHAR(XX),
...
CONTATTI_CAMPON VARCHAR(XX),
TELEFONI_TEL1 VARCHAR(XX),
TELEFONI_TEL2 VARCHAR(XX),
TELEFONI_TEL3 VARCHAR(XX),
INDIRIZZI_IND1 VARCHAR(XX),
INDIRIZZI_IND2 VARCHAR(XX),
INDIRIZZI_IND3 VARCHAR(XX)
);
Va valutata l'ipotesi di un indice sul campo TMP_USER di questa tabella.
Il campo tmp_id viene assegnato tramite un generator.
Avere un id che identifica univocamente un record su questa tabella potrebbe
non servire, ma non si sa mai....
Nel campo USER metti un valore che indica in modo univoco il pc che sta
eseguendo questa operazione:
ip
mac address
serial number hd
...
E' da scartare il nome utente attivo sul pc in quanto potrebbe loggarsi da
altre macchine è causare una duplicazione che sarebbe deleteria.
Poi ti crei una stored procedure che accetta come parametri le chiavi di
ricerca per la tabella contatti.
In base a tale chiavi, cicli sui records master e dettaglio x riempire i
campi della tabella tmp.
Ovviamente, la prima cosa che la procedure fa è:
DELETE FROM TMP_CONTATTI WHERE USER = :AUSER
Poi, alla tua tibquery o quel che è associ:
SELECT * FROM TMP_CONTATTI WHERE USER = :AUSER
Dove :AUSER avrà come valore quello che hai precedentemente passato alla
procedure.
 Quindi la sequenza è:
1) l'utente indica le chiavi di ricerca per i contatti
2) tu richiami la procedure passando le chiavi e un valore che indica
univocamente il pc
3) la procedure, per prima cosa, elimina dalla tabella tmp i records aventi
lo stesso valore che identifica univocamente il pc
4) poi, la procedure cicla sui records restituiti dalla select e riempie una
tabella tmp
5) dalla tua app usi una select su questa tabella usando come parametro
della where il valore univoco usato al punto 2 e al punto 3
Bye
A

 ha scritto nel messaggio
news:bakki2$5bf$1...@newsreader2.mclink.it...


no.
Questa sarebbe RIDONDANZA e violerebbe i principi di normalizzazione.
Avere lo stesso dato scritto in due punti diversi non è una buona idea,
salvo tabelle di consolidamento di dati non + soggetti a modifiche tipo
saldi alla chiusura di bilancio in un db di un sw di contabuilità.
Penasci bene, ogni volta che cambi su tabella telefoni devi poi aggiornare i
dati anche su contatti...
1) perdita di performance.
Se la operazione di modifica dei teelfoni è fatta spesso, il db server deve
occupare parte del suo tempo  per questo inutile compito
2) qualora i 2 dati non fossero allineati quali sarebbe quello esatto?
Ricorda che squando lavori con i db non conta solo la velocità, ma anche la
congruità dei dati, e che entrambe sono garantite fondamentalmente dalla
attenta e accurata progettazione del db in oggetto.
Bye
A

 ha scritto nel messaggio
news:bakm2v$6br$1...@newsreader2.mclink.it...


 Simo

Credo che la soluzione migliore sia creare una stored procedure, ho avuto
un problema simile e l'ho risolto così
Max
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ha scritto nel messaggio
news:balbh8$dud$1...@news.newsland.it...


 ha scritto nel messaggio
news:Bhrza.232164$K35.5...@news2.tin.it...
