Newsgroup: it.comp.lang.delphi
Titolo: Relazioni Firebird e Master/Detail

Usando le relazioni Firebird (Foreign Key), mi aspetterei
un comportamento analogo al Master/Detail, ma non lo
ottengo, mi sfugge proprio il funzionamento delle Relazioni,
salvo che queste funzionino con una Sql Join
Tabella Test            !   Tabella Regioni
------------------------------------------
Nome                      !   CodiceRegione
CodiceRegione        !    NomeRegione
CodiceProvincia      !
CodiceComune       !
ForeignKey creato come segue con IBExpert
Tabella regioni in dipendenza della Tabella Test.
Campo             ! Tabella FK !   Campo FK     !
CodiceRegione ! Test            ! CodiceRegione !
visualizzando i dati su DBGrid, una per Test
e una per le Regioni , al variare del codice
regione su Tabella Test , dovrei vedere il nome
della Regione , ma non cambia.
se invece imposto una relazione Master/Detail tra
Test e Regioni , ottengo il risultato aspettato (vedere
il none regione in base al suo codice)
logicamente con Master/Detail il risultato e' indipendente
dalle Foreign Key.
spero in qualche indicazione
Paolo 

un comportamento analogo al Master/Detail
Ti aspetteresti un comportamento *da chi* ? e che significa "analogo
al Master/Detail" ?.  Per cortesia, quando esponete i vostri problemi,
oltre a fornire informazioni su quale ambiente di sviluppo udate e
quali componenti, adottate un certo formalismo, perché altrimenti
diventa molto difficile arguire dove volete arrivare.
Le relazioni che imposti su un database (creandole mediante foreign
key) servono a consentire l'integrità referenziale dei dati, NON a
creare meccanismi master/detail a livello applicativo.
Durante il disegno dell'applicazione, bisognerà provvedere a mano a
garantire una struttura master/detail ai propri dati.

> garantire una struttura master/detail ai propri dati
nel caso di Tabelle che possono incrociarsi , come ci si comporta , si
impostano a runtime le Master/Detail
ad es:
Tabella Articoli -> Tabella Categorie Prodotti
Tabella Preventivi -> Tabella Articoli -> Tabella Categorie
grazie Paolo

 Master/Detail;
Non ti è molto chiaro il concetto di FK.  L'esistenza di una FK non è
strettamente necessaria perché si possa implementare una logica M/D, ma
serve solo a garantire l'integrità referenziale tra le tabelle.  In
generale, ci può essere una relazione "1 a molti" tra due tabelle, che
corrisponde alla relazione M/D a livello applicativo.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

>
che dire , e' cosi' , forse quanto letto nel sito MS (sotto riportato)
[..]
Per integrità referenziale si intende che la chiave esterna di una qualsiasi
tabella di riferimento deve essere sempre associata a una riga valida della
suddetta tabella.
L'integrità referenziale garantisce che le relazioni tra due tabelle
rimangano sincronizzate durante le operazioni di aggiornamento e di
eliminazione
[...]
mi ha portato a credere che l'uso delle FK, potesse creare una sorta di M/D.
grazie delle indicazioni
ciao Paolo

mi ha portato a credere che l'uso delle FK, potesse creare una sorta di M/D.
Non c'è legame tra le due cose.
Una relazione master/detail è una relazione "logica".  Ad esempio, è
giusto che la struttura fisica di un database preveda che la tabella
delle città abbia una foreign key su quella delle province e quella
delle province una foreign key su quella delle regioni.  Questo
rappresenterebbe la "logica" che sta dietro la suddivisione dei comuni
italiani: ogni regione ha più province, ogni provincia ha più città.
Viceversa, a livello applicativo, le relazioni master/detail possono
essere varie: posso partire da una città e risalire alla provincia di
appartenenza, ad esempio.  In questo caso, la tabella master è quella
delle città, la tabella detail è quella delle province.  Quindi, come
vedi, non c'è una connessione diretta tra le relazioni con foreign key
e le combinazioni master.