Guarda ti incollo un intervento che ho fatto in altri lidi sempre relativo alla gestione gerarchica con qualche esempio specifico.
Se vogliamo affrontare la questione della gestione Gerarchica, serve individuare bene da subito l'esigenza.
Ci sono 2 linee da considerare che si scelgono in base alla profondità richiesta o necessaria.
1) Profondità 1, ovvero 1 Prodotto può avere solo 1 Padre, questo è banale e si ottempera con una Relazione 1-M, ma se questa è l'esigenza l'argomento è già chiuso in quanto banale e non starei nemmeno a considerarlo.
2) Profondità (n) ovvero non definita e volutamente non definibile, quindi da 1÷n, in questo caso ci sarebbero 2 sottoelementi da considerare, ma io preferisco usare sempre quello più flessibile.
Qui parliamo di vera gestione gerarchica ad albero, in cui ogni elemento può avere più figli ma anche che ogni elemento può avere più padri.
In questo caso per la gestione si usano 2 Tabelle fisiche, ma, nella realtà una Tabella viene usata in SELF_REFERENCE... in modo da consentire la gestione ricorsiva a livelli non definiti.
Faccio un esempio culinario, che risulta banale solo per chi non capisce di cosa si parla...
Se vogliamo gestire delle ricette di cucina, dobbiamo comprendere che servono 3 Elementi concettuali:
1) Prodotto: Materie Prime(queste per definizione non avranno mai figli, ma solo padri, ed in questa osservazione sta il concetto di TIPO)
Prezzemolo, Mele, Farina, Acqua ecc...
2) Prodotto: Materie Semilavorate (queste per definizione possono avere sia figli, che padri)
Crema Zabaione, Pasta Frolla, Budino... (queste materie essendo a loro volta costituite da ricette, avranno N figli ma magari uno di essi è a sua volta un Semilavorato)
3) Prodotto: Materia Finale (queste per definizione hanno SOLO figli e nessun genitore)
Torta di Mele (sarà fatta da Pasta Frolla, il semilavorato di prima e... Mele ecc...)
Per realizzare questa struttura(semplifico per la comprensione):
tblProdotti
IdProdotto
Tipo (1=Finito;2=Semilavorato;3=Primo)
Nome
Prezzo
tblRicetta(questa è la tabella che costituisce i rapporti gerarchici, in questo caso culinario è la Ricetta)
IdProdotto
IdParent
Qtà
UM
Nella rappresentazione ER si disegneranno le tabelle in questo modo:
tblProdotti(1)<--->(m)tblRicetta(m)<--->(1) tblProdotti_1
Quella che ho indicato come [tblProdotti_1] è appunto l'utilizzo in SELF_REFERENCE della Tabella prodotti, e consente che ogni elemento possa essere flessibilmente gerarchico.
La distinzione che ho fatto inizialmente, sui 3 tipi è fondamentale quando si realizza l’interfaccia grafica, in quanto si dovrà consentire di selezionare come Ingredienti della Ricetta solo Prodotti con Tipo>1
Ovviamente questo ragionamento banalizzato sulle ricette è solo per facilitarne la comprensione, ma è applicabile a qualsiasi gestione gerarchica Multilivello, produzione di componentistica elettrica/meccanica per la realizzazione di prodotti finiti o parziali.
La difficoltà sta poi nella gestione dell’interfaccia grafica, che va da se che trova la massima chiarezza nell’utilizzo del TreeView in linea concettuale, ma in realtà è solo una questione di organizzazione.
Ci sono poi 2 aspetti da non sottovalutare:
1) Ricavare la DI.BA del prodotto, e di conseguenza il costo complessivo splittato per singolo ITEM con totali parziali e totali generali dello stesso.
2) Stampare l’esploso della DI.BA, i REPORT
Per il primo serve appunto come ti ha indicato anche BSF, usando come DB JET creare una funzione ricorsiva in VBA che partendo dall’Articolo scala la profondità gerarchica e calcola il costo... la funzione da scrivere è banale in se ma non così tanto, diciamo che non è a prova di stupido, e se sei abituato a non dichiarare le Variabili usate e la profondità aumenta, il sistema va in Overflow sicuramente...
Ci sono invece RDBMS che supportano funzioni SQL ricorsive... ed in questo caso la gestione cambia dovendo delegare il Server, e sicuramente cambiano, in meglio, anche le prestazioni.
Quì trovi qualche indicazione:
https://it.qaz.wiki/wiki/Hierarchical_and_recursive_queries_in_SQL
Per il secondo punto invece serve conoscere bene la gestione dei Report.
Mentre per gerarchie ad 1 Livello, ripeto è banale e si gestisce con un Raggruppamento, quando NON si conosce a priori la profondità della Gerarchia, o meglio quando non si è posto un LIMITE stretto alla gerarchia, perché non si sa a prescindere il livello di profondità da rappresentare... questo modo ri gestire l'ambiente non funziona.
In questo caso serve ribaltare i concetti e slegarsi dalla Gerarchia, sfruttando una Tabella dedicata, che consente di SERIALIZZARE i dati da gerarchici a sequenziali come fosse una tabella di Excel, includendo il Livello di profondità gerarchica ed i dati necessari ai ricalcoli.
Il report pertanto diventa semplice da gestire come un banale report MONOLIVELLO, in cui eventualmente si può gestire l’aspetto grafico dell’indentazione sapendo il LIVELLO ed usando Caratteri a spaziatura fissa.
Saluti
@Alex