[supersaibal]Originariamente inviato da andr3a
zalve [/supersaibal]
ciao

mi dite cosa ne pensate ?
secondo voi e' in questo modo piu' semplice gestire anche le modifiche ? ( cambio id del tree al branch e fine dei problemi )
suggerimenti ?
grazie
Bhe è un argomento su cui si può ragionare.

Mi sfugge l'utilità della terza tabella, in che modo andrebbe usata?
Penso che due tabelle siano più che sufficienti, in quanto con una gestisci i dati legati agli elementi che stai trattando (nel caso dell'articolo, tutte le informazioni sugli impiegati) mentre nell'altra gestisci le informazioni sulla gerarchia, per cui la tabella "tree" per come l'hai impostata è già completa, mentre la tabella "branch" va estesa a seconda delle esigenze. "Estesa" nel senso di aggiungere tutti i campi che ti servono, l'esempio dell'articolo era abbastanza minimale.
Questa idea di dividere il tutto in due tabella ha l'utilità, come giustamente dicevi, di slegare questo modo di vedere la struttura gerarchica dal tipo di tabella, o meglio, di slegare la rappresentazione della gerarchia dalle informazioni aggiuntive che non riguardano la gerarchia stessa. E' quindi un vantaggio piu che altro concettuale, cioè memorizzare informazioni diverse (e probabilmente slegate) in posti diversi.

Sui vantaggi pratici ho dei dubbi. Non credo che sia più semplice gestire le modifiche, e cambiare l'id del tree nella tabella branch non mi sembra necessario, in quanto le informazioni sulla gerarchia stanno in tree, non in branch. Se ho interpretato male quello che proponi, prova a fare qualche esempio in piu cosi ci capiamo meglio ma secondo me le modifiche alla struttura verranno gestite in maniera pressoche identica al modello con una tabella unica.

Eventuali svantaggi cosi a prima vista non ne vedo, se non il fatto di introdurre un'ulteriore complicazione in un metodo che già di suo non è troppo immediato. Complicazione che poi si traduce nel dover fare un join, quindi forse troppo complicata non è

Piu tardi provo a ragionarci con piu attenzione