[Best Practice] Salvare 'albero' di categorie/elementi in DB

[MySQL]

Scusa ma cosa "ti turba"?
L'elemento-chiave è la dimensione del packet che scambi con MySQL, che ha una dimensione fissata (a memoria 1MB per le versioni più vecchie).
Normalmente serializzi, come già detto, da applicazione ottenendo una singola stringa.
Poi memorizzi la stringa in un colpo solo dentro un campo (ad esempio TEXT) con una singola operazione.

Per codificare materialmente puoi inventare quello che vuoi; normalmente ti consiglio qualcosa di comodo "simil-JSON" se vuoi fare a mano

albero
   pesche
   mele
   pere
      pere rosse
      pere gialle
fiore
    rosa
        rosa rossa
        rosa gialla
    geranio
       geranio nero
       geranio blu

mettiti comodo contando quanti figli hanno i nodi e quali sono le foglie
albero=3;pesche=0;mele=0;pere=2;pere rosse=0;pere gialle=0; e via così

[LuckySevenRoX]

Scusa ma cosa "ti turba"?
L'elemento-chiave è la dimensione del packet che scambi con MySQL, che ha una dimensione fissata (a memoria 1MB per le versioni più vecchie).
Normalmente serializzi, come già detto, da applicazione ottenendo una singola stringa.
Poi memorizzi la stringa in un colpo solo dentro un campo (ad esempio TEXT) con una singola operazione.

Per codificare materialmente puoi inventare quello che vuoi; normalmente ti consiglio qualcosa di comodo "simil-JSON" se vuoi fare a mano

albero
   pesche
   mele
   pere
      pere rosse
      pere gialle
fiore
    rosa
        rosa rossa
        rosa gialla
    geranio
       geranio nero
       geranio blu

mettiti comodo contando quanti figli hanno i nodi e quali sono le foglie
albero=3;pesche=0;mele=0;pere=2;pere rosse=0;pere gialle=0; e via così

Quindi tu suggerisci di utilizzare una serializzazione per salvare l'intero albero? Scusa ma non è tipo la pratica più sconsigliata del mondo?

Mi rendo conto che ho probabilmente ho spiegato male il mio progetto, ora ci riprovo:
Sto creando uno script che permette di gestire un semplice catalogo di prodotti. Per semplificare la vita all'utente ho implementato una tree-view dove grazie ad un context menu l'utente potrà creare "cartelle" o "prodotti". Attualmente per ogni nuovo inserimento compare un popup dove è possibile inserire le info della categoria o del prodotto. Al salvataggio del popup, vado ad inserire un nuovo row nel DB con i dati (tabella categories o tabella products). Attualmente gestisco la gerarchia con un campo parent_id. Il problema è che il parent_id è consigliato se si ha un numero finito di sottocartelle, ma in questo caso sono potenzialmente infinite, e la ricostruzione degli alberi tramite query, fatta in modo ricorsivo, consuma un grande numero di risorse db. Ovviamente con un solo utente questa cosa non si nota, ma proiettandola su un progetto con migliaia di utenti la storia cambia.

Le mie domande sono due: una relativa al salvataggio effettivo dei dati (dopo averli elaborati nel front-end, se conviene salvarli uno per uno oppure organizzare un sistema di salvataggio 'totale' delle info inserite tramite tree-view).
L'altra relativa all'ottimizzazione della struttura del DB (come dicevo, attualmente utilizzo il parent_id, pratica però sconsigliata per il salvataggio di un numero infiniti di sottonodi).

Quello che suggerisci tu può sicuramente essere considerabile a 'piccoli livelli', ma non posso sfruttare un albero serializzato per fare le query nel DB, non so se mi sono spiegato. Vorrei capire la best practice per creare la struttura del DB per ottenere facilmente le strutture ad albero partendo da un nodo qualunque