Qual è il metodo migliore per separare discussioni annidati in più pagine - per l'applicazione web?

Question

Io sono la progettazione di un display messaggio filettato per un'applicazione PHP / MySQL - come commenti su Slashdot o Youtube - e mi chiedo come devo fare per ordinare i commenti e separandola in pagine in modo che si può avere, diciamo, 20 commenti a una pagina, ma ancora li hanno nidificato.

I commenti nel mio app possono essere nidificati livelli illimitati, e questa struttura è rappresentato utilizzando quello che credo è un tavolo Adjacency Relazione, una tabella separata che contiene una riga per ogni coppia che abbia un rapporto ascendente / discendente. Quel tavolo rapporto ha CHILDID, ParentID e livello in cui un livello di 2 significa "bisnonno", e così via.

La mia domanda è uno dei due usabilità per l'utente finale, e di praticità di costruire una query DB efficiente. Ho preso in considerazione queste opzioni:

• Risultati Splitting in pagine per data, indipendentemente dalla posizione nella struttura, in modo che tutti i commenti entro un certo intervallo di date appariranno insieme anche se non appaiono con i loro genitori. Ogni commento che è stato pubblicato in un momento simile al suo genitore apparirà sulla stessa pagina e in quei casi siamo in grado di mostrare 'annidata', ma ci saranno commenti che sono orfani dai loro genitori. Questo è probabilmente accettabile, - è il modo in cui le cose vengono fatte nei commenti di YouTube - un commento fatto molto più tardi rispetto al suo genitore non apparirà sulla stessa pagina come suo padre (se il genitore non è sull'ultima pagina), ma appaiono invece con gli altri commenti più recenti.

• Recuperare i nodi in modo come si farebbe attraversare un albero. Questo dà la priorità alla struttura ad albero piuttosto che la data, anche se i fratelli possono ancora essere ordinati per data. Il vantaggio di questo è che le risposte sono sempre posto con i loro genitori (il commento sono in risposta a), anche se quel genitore è un certo numero di pagine i più recenti commenti. Questo è il modo le cose vengono fatte su applicazioni come ad esempio il blog icanhascheezburger. Non mi piace un paio di cose su di esso, come il modo in cui ognuno è tentato di aggiungere una risposta a tutto ciò che è il ramo di un albero più grande.

• La terza opzione è quella di fare come Slashdot fa, dove non separa i commenti nelle pagine, ma ha un grande albero -. Al fine di mantenere le dimensioni della pagina gestibile inizia abbattimento commenti a basso rating, invece

Penso che la prima sarebbe la query più semplice DB dato la mia tabella di relazione, ma sarebbe aperto ad altre idee.

Alcuni di questi sistemi, di tutti i tre tipi, limitare il livello di nidificazione in qualche modo - questo è abbastanza facile da fare, una volta che abbiamo ricorsivo su X livelli di tutto il resto possono essere combinati insieme come se fossero fratelli. Ad esempio, i commenti di YouTube rendono solo per un livello. Altri sistemi a volte dicono "livello di nidificazione superato" dopo 5 o giù di lì i livelli.

Answer 1

Suppongo che la ragione si desidera commenti nidificati a tutti è perché gli utenti tendono a voler leggere un singolo thread di interesse alla volta. Cioè, si ha ragione di credere che gli utenti potranno creare fili di catene coerenti di pensiero, e / o di ciò che viene discusso in un thread interesserà alcuni utenti ma non altri.

Se questo è il caso, non so il motivo per cui si sarebbe mai desidera dividere arbitrariamente un filo tra le pagine per data (opzione 1). Utilizzando una singola pagina con abbattimento di basso rating commenti (opzione 3) sembra un po 'dura e può scoraggiare gli utenti dal pubblicare commenti. Che può essere una buona cosa se hai una massa pubblico come Slashdot, ma può essere indesiderabile per i siti con più tassi tipici di visita.

Forse si può avere qualcosa di simile opzione 2, con tutte le discussioni sulla stessa pagina, ma se un thread comincia a diventare troppo lungo, esso viene arrotolato in un unico link che porta l'utente a una pagina dedicata a questo thread. In alternativa, lunghi fili possono essere ridotti per visualizzare solo le righe dell'oggetto e autori, ciascuno a sua volta di collegamento nella posizione appropriata in una pagina dedicata per il filo.

Ho il sospetto che la tendenza degli utenti per inviare commenti irrilevanti nel thread più grande è un prodotto di utenti non voler essere disturbato con lo scorrimento intorno per trovare il capo del filo, o di trovare un filo che è più adatto. Compattando automaticamente filettature lunghe, lasciando la radice di tutte le discussioni visualizzati in una singola pagina di lunghezza gestibile, gli utenti possono facilmente eseguire la scansione di un filo di interesse e aggiungere ad essa, se desiderato.

Answer 2

Penso che quello che vi serve è la memorizzazione di un dati gerarchici in un database. Si dovrebbe iniziare con questo articolo: articolo a SitePoint articolo sul sito di MySQL