[Articolo] Strutture gerarchiche su database (Articolo completo)

[mircov]

una volta che hai la classe ti conviene utilizzare questo metodo che sicuramente è più veloce e meno dipendioso.

[andr3a]

Originariamente inviato da scitrek
Scusate, ci sono un paio di particolari che non ho ben capito...

E' possibile avere diverse categorie capostipiti, come nell'Adjacency List Model, oppure devono essere tutte figlie della root (tipo albero, quindi)?

Ci sono casi particolari in cui conviene usare l'ALM invece che questo?

scusa ma con il solito parent_id come fai ad avere piu' categorie capostipiti ?

Comunque avevo pensato anche io alla problematica "piu' di un genitore" ma alla fine con la tabella slegata puoi mettere quello che ti pare, tipo un id marca e lavorare con una terza tabella ... tipo

hardware
-video
--scheda video
----monitor
----proiettore
-memoria
--hard disk
--ram

e per ogni prodotto raggruppare ulteriormente per marca , cosi' hai gerarchie interne raggruppate ... poi per il discorso piu' di un percorso o piu' di una dipendenza penso che bisognerebbe clonare i nodi su piu' punti e usare una tabella di riferimento qualora vlessi aggiornare uno dei clonati, al fine di aggiornare anche tutti gli altri.

o no ? :master:

[mircov]

Copn il solito parent id io per avere più nodi mettevo come parent_id 0. In questo modo tutte le cat che avevano parent_id = 0 erano root.

Per la seconda parte del post... non ho capito un... niente! :master:

[M4rko]

Originariamente inviato da scitrek
Scusate, ci sono un paio di particolari che non ho ben capito...

E' possibile avere diverse categorie capostipiti, come nell'Adjacency List Model, oppure devono essere tutte figlie della root (tipo albero, quindi)?

Ci sono casi particolari in cui conviene usare l'ALM invece che questo?

Così come è presentato nell'articolo, la radice deve essere unica.
Per aggirare il problema ti basta creare una radice fittizia, e poi i nodi che saranno capostipiti dovranno essere figli di questa. Ovviamente poi devi ricordarti di questo particolare in modo da "nascondere" all'utente il nodo fittizio.

[andr3a]

Originariamente inviato da mircov
Copn il solito parent id io per avere più nodi mettevo come parent_id 0. In questo modo tutte le cat che avevano parent_id = 0 erano root.

Per la seconda parte del post... non ho capito un... niente! :master:

come ha detto marko ovviamente basta mettere la root , poi li sotto fai quello che ti pare ... nella select basta mettere sx > 1 e hai finito i problemi delle multiple radici.

In pratica il nodo base e' indispensabile, se non lo vedi, non sai nemmeno che c'e' e l' unico "inconveniente" e' se mostri a video sinistra e destra, notando che il primo partira' con sinistra = 2 e non 1

[mircov]

A parte che la radice unica è utile per il path.

[scitrek]

Grazie delle risposte, una ulteriore domanda: questo tipo di architettura è conveniente per gestire categorie incrociabili? In altre parole, vorrei fpoter far si che un singolo prodotto possa far parte di diverse categorie, senza dovermi preoccupare a monte di quante...

[M4rko]

Originariamente inviato da scitrek
Grazie delle risposte, una ulteriore domanda: questo tipo di architettura è conveniente per gestire categorie incrociabili? In altre parole, vorrei fpoter far si che un singolo prodotto possa far parte di diverse categorie, senza dovermi preoccupare a monte di quante...

In questo caso il modo in cui memorizzi le categorie probabilmente è indifferente visto che la relazione prodotto-categorie andrebbe gestito su una tabella a parte.

Esempio semplice:
tabella categorie, implementata col metodo che preferisci
tabella prodotti, con tutti i campi che ti servono
tabella prodotti_categorie ( id_prodotto, id_categoria ), che gestisce la relazione

[M4rko]

Originariamente inviato da mircov
A parte che la radice unica è utile per il path.

In che senso è utile per il path?
A mio avviso è indifferente :master:

Con l'adjacency list puoi tranquillamente avere piu radici, basta che abbiano il parent_id uguale a zero (o NULL, basta mettersi d'accordo)
Se invece ti riferisci al modified preorder ecc. , tieni presente che il path puoi ricostruirlo da un punto qualsiasi dell'albero.
Cioè ad esempio se hai:
Radice -> Categoria -> Sottocat -> Sottosotto -> Elemento,
puoi tranquillamente costruire il percorso anche solo da Categoria in poi

[mircov]

No, non mi sono spiegato. Qui si stanno chiedendo in molti come fare ad avere più radici ma secondo me è inutile. A parte che avete già detto voi che basta eliminare la prima occorrenze ritornata dal db per poter avere lo stesso effetto cmq a mio avviso è comoda. Mettiamo il caso che io stia facendo un catalogo: la mia radice la chiamerò "atalogo" e quando dalla home cliccherò sul link la parola catalogo verrà inserita in automatico cosa che pima invece non succedeva perchè dovevo mettere io la sezione del sito in cui si era. Forse dipenderà anche dal fatto che allora ero molto più inesperto però in questo io ci trovo un'enorme comodità.