La risposta è: non esiste.
La gestione relazionale di MySQL non è fatta per la gestione ad oggetti, quindi una struttura ad albero la devi "impacchettare" in qualche modo.
Se la materializzi sotto forma di tabelle va bene.
Se la materializzi serializzata in un singolo campo va bene, anzi può andare anche benissimo se il sito è ad alta concorrenza.
Perchè ogni client si "spacchetta" (o pacchetta) il suo albero dei dati, e son 'zzi suoi (senza caricare il db nè interferire con gli altri utenti).
Il "piccolo" particolare è javascript, che non è esattamente l'ambiente più affidabile per gestire grandi quantità di dati.
Spiega magari meglio questo, perchè francamente non è che abbia capito molto
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.
Non esistono, per quanto ne so, ricorsioni con query MySQL, quindi non mi è chiarissimo il significato.
Riguardo al numero finito... che ti frega, metti un limite massimo di profondità dell'albero e bon, fine del dramma.
"Numero infinito di sottonodi", con tutto il rispetto, non significa nulla (anche perchè le macchine sono ontologicamente limitate, quindi un upperbound nei nodi ce l'hai, eccome).

Ho come l'impressione che ti stai ponendo problemi sbagliati: fossi in te sarei 1000 volte più preoccupato di gestire in modo affidabile un albero molto grande con javascript, piuttosto che caricare il db.


L'albero serializzato può essere acceduto a velocità decisamente maggiore utilizzando un motore di ricerca fulltext (lucene,sphinx) qualora volessi cercare le sottostringhe che compongono l'albero.