Come faccio a implementare i commenti filettati?

Question

Sto sviluppando un'applicazione web in grado di supportare i commenti filettati. Ho bisogno della capacità di riorganizzare i commenti in base al numero di voti ricevuti. (Identico al lavoro commenti come filettato in reddit )

Mi piacerebbe sentire gli ingressi dal SO comunità sul come farlo.

Come faccio a progettare le Commenti da tavolo? Ecco la struttura che sto usando ora:

Comment
    id
    parent_post
    parent_comment
    author
    points

Ciò che cambia dovrebbe essere fatto a questa struttura?

Come faccio a ottenere i dettagli da questa tabella per visualizzarli in modo corretto? (Attuazione in qualsiasi lingua è il benvenuto. Voglio solo sapere come farlo nel miglior modo possibile)

Quali sono le cose che ho bisogno di prendersi cura durante l'implementazione di questa funzione in modo che ci sia meno carico sulla CPU / Database?

Grazie in anticipo.

Answer 1

Memorizzazione di alberi in un database è un argomento che ha molte soluzioni diverse. Dipende se si vuole recuperare un subhierarchy così (in modo che tutti i bambini della voce X) o se volete semplicemente per afferrare l'intero set di gerarchie e di costruire l'albero in modo O (n) in memoria utilizzando un dizionario.

Il tavolo ha il vantaggio che è possibile recuperare tutti i commenti su un post in 1 Go, filtrando sulla parentpost. Come avete definito padre del commento nel libro di testo / modo ingenuo, è necessario costruire l'albero in memoria (vedi sotto). Se si desidera ottenere l'albero dal DB, è necessario un modo diverso per memorizzare un albero: Vedere la mia descrizione di un approccio basato sulla pre-calc qui: http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID = 17746 & ThreadID = 3208 o basati su alberi bilanciati descritto da Celko qui :

o ancora un altro approccio: http://www.sqlteam.com/article/more-trees-hierarchies -in-sql

Se si recupera tutto in una gerarchia nella memoria e costruire l'albero lì, può essere più efficiente a causa del fatto che la query è piuttosto semplice: scegliere .. da dove Commento ParentPost = @id ORDER BY ParentComment ASC

Dopo che query, è costruire l'albero in memoria con appena 1 dizionario che tiene traccia del CommentID tupla - Commento. Ora si cammina attraverso il gruppo di risultati e costruire l'albero al volo: ogni commento si esegue in, si può cercare la sua parentcomment nel dizionario e quindi memorizzare il commento attualmente elaborata anche in quel dizionario.

Answer 2

Un paio di cose da considerare anche ...

1) Quando si dice "sorta come Reddit" sulla base di rango o la data, vuoi dire il primo livello o il tutto?

2) Quando si elimina un nodo, che cosa succede ai rami? Ti ri-genitore loro? Nella mia applicazione, sto pensando che gli editori a decidere - o nascondere il nodo e visualizzarlo come "commento nascosta", insieme con i bambini a vista, nascondere il commento ed è bambini, o Nuke tutto l'albero. Re-genitorialità dovrebbe essere facile (basta impostare padre del chidren al genitore eliminato), ma tutto ciò che coinvolge tutto l'albero sembra essere difficile da implementare nel database.

Sono stato a guardare il modulo ltree PostgreSQL. Si dovrebbe rendere le operazioni di database che coinvolgono parti della pianta un po 'più veloce. Consente in pratica si imposta un campo nella tabella che appare come:

ltreetest=# select path from test where path <@ 'Top.Science';
                path                
------------------------------------
 Top.Science
 Top.Science.Astronomy
 Top.Science.Astronomy.Astrophysics
 Top.Science.Astronomy.Cosmology

Tuttavia, non garantisce alcun tipo di integrità referenziale da solo. In altre parole, si può avere un record per "Top.Science.Astronomy" senza avere un record per "Top.Science" o "Top". Ma ciò che fa ti permette di fare cose del genere è:

-- hide the children of Top.Science
UPDATE test SET hide_me=true WHERE path @> 'Top.Science';

o

-- nuke the cosmology branch
DELETE FROM test WHERE path @> 'Top.Science.Cosmology';

Se combinato con il tradizionale "COMMENT_ID" / approccio "parent_id" utilizzo di stored procedure, sto pensando è possibile ottenere il meglio dei due mondi. È possibile attraversare rapidamente il commento albero nel database utilizzando il vostro "percorso" e ancora assicurare l'integrità referenziale tramite "COMMENT_ID" / "parent_id". Sto immaginando qualcosa di simile:

CREATE TABLE comments (
comment_id SERIAL PRIMARY KEY,
parent_comment_id int REFERENCES comments(comment_id) ON UPDATE CASCADE ON DELETE CASCADE,
thread_id int NOT NULL  REFERENCES threads(thread_id) ON UPDATE CASCADE ON DELETE CASCADE,
path ltree NOT NULL,
comment_body text NOT NULL,
hide boolean not null default false
);

La stringa di percorso per un commento assomigliare essere

<thread_id>.<parent_id_#1>.<parent_id_#2>.<parent_id_#3>.<my_comment_id>

Così un commento radice del filetto "102" con un COMMENT_ID di "1" avrebbe un percorso di:

102.1

E un bambino la cui COMMENT_ID è "3" potrebbe essere:

102.1.3

Una alcuni figli di "3" con id di "31" e "54" potrebbe essere:

102.1.3.31
102.1.3.54

Per nascondere il nodo "3" ed i suoi figli, che ci si emette questo:

UPDATE comments SET hide=true WHERE path @> '102.1.3';

Non so se - si potrebbe aggiungere in testa inutile. Inoltre non so quanto bene ltree mantenuto è.

Answer 3

Il design attuale è fondamentalmente bene per le piccole gerarchie (meno di mille articoli)

Se si vuole prendere a livello certian o profondità, aggiungere una voce di 'livello' per la vostra struttura e calcolare come parte del salvataggio

Se le prestazioni sono un problema utilizzare una cache decente

Answer 4

mi piacerebbe aggiungere i seguenti nuovi campi per tabel sopra:

• ID_Thread: identificatore per tutti i commenti collegati a un oggetto specifico

• Data: la data di commento (consente il recupero delle osservazioni in ordine)

• Classifica: il commento rango (consente di andare a prendere l'ordine commento di ranking)

L'utilizzo di questi campi che sarete in grado di:

1. recuperare tutti i commenti in un thread in un unico op
2. commenti dell'ordine in un filo o per data o rango

Purtroppo, se si desidera conservare le vostre domande DB vicino allo standard SQL dovrete ricreare l'albero in memoria. Alcuni DB stanno offrendo query speciali per i dati gerarchici (f.e. Oracle)

./ alex