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

[LuckySevenRoX]

Buongiorno, sto cercando di risolvere nel modo migliore un problema, suppongo, abbastanza comune. Ho creato un backend che permette di creare in modo totalmente dinamico una serie di categorie/sottocategorie/elementi direttamente nella stessa pagina (tutto in JS).

Il salvataggio, attualmente, avviene cliccando su un bottone 'salva'. Questo significa che posso creare anche 100 categorie e 1000 elementi, ma se non clicco su salva tutto andrà perduto.

Il problema di questo approccio è proprio questo: se qualcuno inizia a inserire 100 prodotti c'è il rischio che perda tutto. La mia idea era di distribuire il salvataggio in modo più elegante e senza ricevere una massa di dati annidati, ma anche questa soluzione presenta alcuni problemi:

- se creo un elemento, figlio di Categoria > Sottocategoria, e voglio salvarlo, dovrei salvare prima anche le categorie in cui è contenuto, andando a fare comunque un "elevato" numero di query.

Non so, vorrei discutere con voi su quale può essere la soluzione migliore da adottare!

[MySQL]

Non è che abbia capito benissimo, ma in sostanza devi serializzare l'albero (qualcuno direbbe elegantemente "come una diagonalizzazione di Cantor"), una sorta di JSON-none.
Poi ci metterai un flag del tipo "salvataggioautomatico" e "salvataggiodell'utente", così da poter purgare tutti quelli NON salvati effettivamente dall'utente.

[plaastico]

Non ti conviene salvare automaticamente le modifiche attraverso un timeout di attività e una funzione di salvataggio/aggiornamento AJAX?

[LuckySevenRoX]

per il momento salvo tutto step per step, ovvero creo una categoria e salvo.. il problema non è non riuscire a salvarli, per farlo ci sono mille modi, volevo capire qual'era il modo migliore per farlo (e per best-practice mi riferisco soprattutto al modo migliore per evitare sprechi di performance del db utilizzando troppe query).

Il secondo problema è la best practice per salvare più categorie annidate in un DB... mi sto informando un pò ma tanto ci sono sempre vantaggi/svantaggi legati a diversi fattori, dove una soluzione è migliore in fase di lettura e una è migliore in fase di scrittura.. su come salvare alberi di informazioni su mysql avete suggerimenti?

[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

[MySQL]

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.

[Al_katraz984]

A mio avviso dovresti fare un salvataggio per ogni categoria/sotto-categoria che viene inserita cosi ti eviti gran parte degli sbattimenti.

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).

se non usi 1 tabella te ne servono 3, categoria cat_subcat e subcat ma questo dipende se vuoi o meno la possibilità di avere categorie doppie/personali oppure no.. dipende dalla struttura del tuo sistema