Pagina 18 di 22 primaprima ... 8 16 17 18 19 20 ... ultimoultimo
Visualizzazione dei risultati da 171 a 180 su 217
  1. #171
    una volta che hai la classe ti conviene utilizzare questo metodo che sicuramente è più veloce e meno dipendioso.

  2. #172
    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:
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  3. #173
    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:

  4. #174
    Utente di HTML.it L'avatar di M4rko
    Registrato dal
    Dec 2000
    Messaggi
    619
    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.
    Tutti hanno bisogno di credere in qualcosa.
    Io credo che mi farò un'altra birra.


  5. #175
    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
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

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

  7. #177
    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...

  8. #178
    Utente di HTML.it L'avatar di M4rko
    Registrato dal
    Dec 2000
    Messaggi
    619
    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
    Tutti hanno bisogno di credere in qualcosa.
    Io credo che mi farò un'altra birra.


  9. #179
    Utente di HTML.it L'avatar di M4rko
    Registrato dal
    Dec 2000
    Messaggi
    619
    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
    Tutti hanno bisogno di credere in qualcosa.
    Io credo che mi farò un'altra birra.


  10. #180
    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à.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.