Newsgroup: it.comp.appl.access
Titolo: Alberi e database

Devo costruire una struttura per contenere gli articoli di vendita, che sono
organizzati in una struttura gerarchica:
-Ortaggi
        --Insalate
                ---Belga
                ---Lattuga
        --Pomodori
                ---Ciliegia
                ---Verdi da insalata
-Frutta
        --Mele
                ---Stark
                ---Steinbeck
        --Pere
                ---William
                ---Abate Fetel
Questa struttura ad albero deve essere gestita con tabelle. Io ho pensato a
tre soluzioni, ma nessuna e' completamente soddisfacente:
1) Usare una tabella per livello: tblGruppi (Ortaggi, Frutta),
tblSovraProdotti (Insalate, Pomodori, ...), tblProdotti (Belga, Lattuga,
Ciliegia, ...) ognuna collegata al livello superiore.
    PRO : facile da realizzare, integrita' referenziale della struttura
garantita, facile renderla in maschere con i fogli secondari.
    CONTRO : molto difficile inserire un nuovo livello di organizzazione,
tante tabelle, tabelle con nomi poco significativi.         Recuperare
informazioni sugli antenati (dato Abate Fetel trovare Frutta) e discendenti
(dato Ortaggi trovare Belga, Lattuga, Ciliegia e Insalata) e' difficile e
poco efficiente.
2) Usare una tabella con relazione padre/figlio : tblArticoli con struttura
        idArticolo, Articolo, IdArticoloPadre
        1                Ortaggi    Null
        2                Insalate    1
        3                Belga       2
        4                Lattuga    2
        2                Frutta      Null
        ...                ...            ...
    PRO : l'integrita' referenziale e' garantita. Puo' contenere un numero
arbitrario di livelli senza alcun problema.
    CONTRO : la gestione di questa struttura deve essere fatta in maniera
ricorsiva perche' non e' noto il numero di livelli e     SQL non ha
strutture ricorsive. Recuperare antenati e discendenti e' difficile e poco
efficiente. Non e' facile vedere e ordinare i record per leggere
direttamente la tabella. Non si puo' gestire con i fogli secondari ma solo
con un controllo treeview.
3) Usare una tabella con un campo per indicare il livello:
        L0    L1    L2    L3        Articolo
        0    Null    Null    Null    Ortaggi
        0    0        Null    Null    Insalate
        0    0        0        Null    Belga
        0    0        1        Null    Lattuga
        1    Null    Null    Null    Frutta
        1    0        Null    Null    Mele
        ..    ...    ...            ...        ...
    PRO : la tabella e' facile da ordinare e leggere direttamente, il
recupero di antenati e discendenti e' efficiente e semplice, il codice puo'
essere usato anche dall'utente perche' abbastanza naturale.
    CONTRO : l'aggiunta di un livello richiede l'aggiunta di un campo e
della relativa gestione. L'integrita' referenziale non e' garantita (o
almeno io non capisco come). Si puo' gestire anche se non in modo immediato
con i fogli secondari.
Lo stesso problema si presenta, per esempio, con il piano dei conti.
Mi sono chiesto che soluzioni adottano gli altri, se c'e' modo di superare i
contro... Se qualcuno e' interessato ad approfondire, penso sarebbe utile
inserire le considerazioni in una faq per avere almeno un punto di partenza.
Luca

 Mi sono chiesto che soluzioni adottano gli altri...
Non c'e' molto da pensare, basta ragionare sul perche' nascono i db
relazionali.
Il tuo e' il classico esempio (da accademia direi) che dimostra, senza dare
adito a dubbi, le ragioni per cui sono stati inventati questi tipi di
database.
Perfino con le autocomposizioni puoi creare la struttura delle tabelle e
delle maschere con sottomaschere perfettamente in grado di gestire in modo
rapido ed efficiente la struttura di cui parli.
Sib
--
----------------------------------------------------
la mia home:
http://digilander.iol.it/syb
----------------------------------------------------
il sito comune di it.comp.database.access:
http://www.sitocomune.com
----------------------------------------------------
4000 anni fa', il saggio egizio Ptahhotep scrisse:
"... perche' non esistono saggi per nascita."
------------------------------------------------------
Saturiamo ECHELON:
bomba saddam attentato medio oriente

 ha scritto nel messaggio
news:a1yH6.14486$0t6.5...@news.infostrada.it...

mi sembra opinabile, bisognerebbe sapere di preciso cosa deve gestire, se e'
una struttura nota puo' andare bene cosi', se non sa a priori a che livelli
deve arrivare
deve quasi per forza usare una struttura ad albero binario.
comunque vba supporta la ricorsivita' e le istruzioni sql basta incapsularle
in una routine vba ricorsiva e il tutto funziona.
ciao
Giancarlo

 in una routine vba ricorsiva e il tutto funziona.
Non mi sembra affatto che sia opinabile.
Per creare un nuovo sottolivello si puo' creare da codice una nuova tabella
legata alla precedente, quindi quella resta la soluzione piu' semplice ed
efficiente.
