petrusic:
Nel mio progetto di contabilità familiare, faccio uso di griglie di dati che vorrei fare funzionare ora come dei veri e propri array, dove riportare tutte le colonne (visibili e non) delle tabelle logiche caricate in memoria tramite un'unica o più ZQuery (ancora non so come muovermi). Fino ad ora ho utilizzato oggetti TStringGrid. Ora sto pensando di prendere conoscenza e sfruttare le DBGrid con Zeoslib. Nella brevissima guida ho letto che, nell'unica tabella fisica di esempio, si è dovuto aggiungere --- Citazione ---il campo IdPickExternalKey alla tabella principale in modo che faccia da chiave esterna ... --- Termina citazione --- . Se senza quel campo la DBGrid non funziona, allora posso gettare la spugna, perchè il DB in uso nel mio attuale progetto, scritto tuttto in Gambas, viene letto e aggiornato giornalmente e non posso stravolgere l'attuale funzionalità del software corrente.
Sto facendo poi una riflessione: Se avessi bisogno di scrivere una "SELECT * FROM Tabella1, Tabella2, Tabella3 WHERE . . . " dove si costruirebbe una tabella logica con le colonne di più tabelle fisiche, come dovrei costruire la chiave esterna a cui si riferisce l'esempio della suddetta miniguida?
DragoRosso:
Ok, se ho capito bene vuoi con una query interrogare tre tabelle e generare una unica tabella "virtuale".
A rigore di logica, una chiave "comune" è necessaria se devi collegare dei contenuti (righe) di diversi contenitori (tabelle).
E' particolarmente ovvio che qualcosa che lega i contenuti tra le tabelle ci deve essere, e quel qualcosa viene chiamato "foreign key". E' un concetto abbastanza comune, che può essere gestito anche senza questa "chiave" a livello di codice.
La chiave "foreign key" è il collante tra le tabelle e consente senza interventi di codice esterno di effettuare query più o meno semplici per aggregare dati.
Questa argomento è un pò più ampio e si collega alla progettazione dei database, avendo chiaro in mente cosa si deve fare. Nel tuo caso hai creato un insieme di dati per essere usato in una applicazione "GAMBAS", usarlo con un'altra applicazione potrebbe non essere così trasparente ed immediato.
Per poterti aiutare ci servirebberero ulteriori info sul database e sulle tabelle.
Ti posto quanto prima un esempio da cui puoi prendere spunto.
Ciao
DragoRosso:
Esempio di join di tre tabelle senza foreign key.
Questa è la stringa SQL:
--- Codice: --- Select Utenti.Nome, Utenti.Cognome, ElencoScontrini.NumeroScontrino, Costo.Valore, ElencoScontrini.Data FROM Utenti join ElencoScontrini on RifUtente = ID join Costo on RifScontrino = ID1 --- Termina codice ---
In allegato database e printscreen risultato.
Ti lascio il piacere di "convertire" la stringa SQL per ZEOS ;)
DragoRosso:
Questa invece è il database (sempre SQLITE) con una foreign key.
Sembra identico, e anche la stringa SQL è identica e ovviamente anche il risultato.
Allora perchè usare una foreign key ?
La risposta è semplice:
prova ad eseguire un inserimento nella tabella Costo di una riga con RifScontrino = 6. Fallo in tutti e due i database e vedrai la differenza.
A questo servono le "foreign key", a mantenere l'integrità dei dati .... almeno formalmente. Spero di esserti stato di aiuto.
Saluti
petrusic:
--- Citazione da: DragoRosso - Ottobre 02, 2021, 01:14:19 am ---A questo servono le "foreign key", a mantenere l'integrità dei dati .... almeno formalmente. Spero di esserti stato di aiuto.
--- Termina citazione --- Grazie per avere cercato di aiutarmi. In verità avevo capito che la chiave esterna non è altro che una sorta di meccanismo automatico di sicurezza sui dati. Io volevo solo sapere se l'impiego della DBGrid per eseguire una query su Join di tabelle comportasse obbligatoriamente la dichiarazione di una chiave esterna. Dai tuoi due esempi di DB SQLite, capisco implicitamente che l'obbligo assoluto non esiste.
Ora, considerando che io non voglio usare la DBGrid per inserire o modificare record, direttamente al suo interno, al fine di evitare di modificare una casella al posto di un'altra (potrebbe capitare), dovrei impostare il parametro ReadOnly = False.
A questo punto, credo che tanto vale continuare ad utilizzare laStringGrid.