Newsgroup: it.comp.appl.access
Titolo: Distinte base a livelli infiniti

Qualche tempo fa ho postato un paio di messaggi
con lo stesso subject (rimasti pero' senza risposta)
dove chiedevo un parere sul modo in cui io avrei risolto la questione.
Successivamente, in un altro thread, Roberto Pasqualini
spiegava che le distinte base di questo tipo
vengono solitamente strutturate usando "tabelle autoreferenziate",
senza pero' approfondire come organizzare il DB
(io ho fatto anche qualche tentativo per relazionare
la tabella tblDistinteBase con se stessa, ma senza successo).
C'e' qualcuno nel NG che ha avuto a che fare con queste "bestie"
e che mi puo' dare qualche 'dritta' su come organizzare
le strutture dati?
Grazie
---
leo_duca

Innanzitutto è bene precisare che una tabella autoreferenziata non è un
mostro, bensì una tabella in cui un campo (Indicizzato ma con la possibilità
di duplicati) è relazionato con un campo (Chiave primaria) della stessa.
Si costruisce in questo modo una struttura ad albero in cui in ogni record
(foglia) viene indicato l'Id del record padre. Tutti i record che avranno
questo valore settato a null saranno da considerare nodi radice, quelli con
un indice <> Null saranno nodi intermedi.
Ad esempio: dato X articolo complesso, e dati A, B, C le sue componenti.
Inoltre A è formato da H,K avremo la seguente struttura:
Cont       Descrizione        IdPadre
   1             X                     NULL
   2             A                       1
   3             B                       1
   4             C                       1
   5             H                       2
   6             K                       2
A questo punto nascono però alcuni problemi di non facile risoluzione (o che
comunque richiedono un overhead aggiuntivo non indifferente). Il principale
è quello dei cicli. Un esempio banale potrebbe essere il caso in cui viene
settato come IdPadre il Cont del record stesso.
Spero di essere stato chiaro.
ErSoft

 di duplicati) è relazionato con un campo (Chiave primaria) della stessa.
Ti ringrazio per la risposta.
Io ho gia' implementato una struttura 'standard'
ad albero ed ho gia' scritto le varie routine di
visita ricorsiva, verificando anche eventuali chiusure
'ad anello' (es. distinta figlio che contiene distinta padre).
La questione che non mi soddisfa e' quella indicata
nella parte sopra quotata del tuo messaggio .
Infatti, come dicevo nel mio post, ho provato
a creare una relazione tra la tabella tblDistinteBase
e se stessa (tra i campi rifDistintaFiglio' e 'IdDistinta')
ma Access mi da dei messaggi di errore (ora non ricordo quali)
quando uso il campo 'rifDistintaFiglio '
    tblDistintaBase
        IdDistinta    (chive primaria)
        DescrizioneDistinta
        rifDistintaFiglio
        rifProdotto
        ...
A dir la verita' la soluzione che adotto ora ha anche
i suoi vantaggi ma il fatto di lavorare senza
quella relazione (costretto quindi a fare tutta
una serie di controlli 'a mano') non mi fa mai stare tranquillo.
Per non parlere poi del fatto che sono limitato
nell'uso delle query!!
Ciao e grazie :)
---
leo_duca

         ...
Dall'analisi di questa struttura sembra che il padre (articolo complesso)
debba avere un campo con gli id dei figli (componenti).
La soluzione da me prospettata era l'inverso cioè:
      tblDistintaBase
         IdDistinta    (chive primaria)
         DescrizioneDistinta
         rifArticolo
         rifDistintaPadre
         ...
in questo modo è possibile definire una relazione tra il campo IdDistinta
(1) e il campo rifDistintaPadre (molti), duplicando le tabelle nella
maschera relazioni.
E' inoltre possibile applicare alla relazione criteri integrità referenziale
(prima di farlo ti consiglio di svuotare la tabella, altrimenti potrebbe
darti errori di incongruenza dati), Aggiornamenti ed eliminazioni a catena.
ErSoft

          ...
Cosi' facendo, come fa una distinta ad essere figlia
di piu' padri???
---
leo_duca