Como posso implementar comentários de rosca?

Question

Estou desenvolvendo uma aplicação web que pode suportar comentários de rosca. Eu preciso a capacidade de reorganizar as observações com base no número de votos recebidos. (Idêntico aos comentários como rosca trabalho na reddit )

Eu gostaria de ouvir as entradas da comunidade SO sobre como fazê-lo.

Como devo projetar os comentários mesa? Aqui é a estrutura que estou usando agora:

Comment
    id
    parent_post
    parent_comment
    author
    points

Que mudanças devem ser feitas a esta estrutura?

Como devo obter os detalhes desta tabela para exibi-los da maneira correta? (Implementação em qualquer língua é bem-vindo. Eu só quero saber como fazê-lo da melhor maneira possível)

O que são as coisas que eu preciso tomar cuidado ao implementar esse recurso para que haja menos carga no CPU / banco de dados?

Agradecemos antecipadamente.

Answer 1

O armazenamento de árvores em um banco de dados é um assunto que tem muitas soluções diferentes. Depende se você deseja recuperar um subhierarquia bem (assim todas as crianças do inciso X) ou se você só quer agarrar todo o conjunto de hierarquias e construir a árvore de forma O (n) na memória usando um dicionário.

A sua mesa tem a vantagem de que você pode buscar todos os comentários em um post em um movimento, filtrando na parentpost. Como você definiu pai do comentário da maneira livro / ingênuo, você tem que construir a árvore na memória (veja abaixo). Se você deseja obter a árvore do DB, você precisa de uma maneira diferente para armazenar uma árvore: Ver a minha descrição de uma abordagem baseada pré-calc aqui: http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID = 17746 & ThreadID = 3208 ou por usando árvores equilibradas descrito por Celko aqui :

ou ainda outra abordagem: http://www.sqlteam.com/article/more-trees-hierarchies -in-sql

Se você buscar tudo em uma hierarquia de memória e construir a árvore lá, ele pode ser mais eficiente devido ao fato de que a consulta é bastante simples: escolha .. de comentário Onde ParentPost = @ id ORDER BY ParentComment ASC

Após essa consulta, você construir a árvore na memória com apenas um dicionário que mantém o controle do CommentID tupla - Comentário. Agora você percorrer o conjunto de resultados e construir a árvore na mosca: cada comentário você tiver, você pode consultar a sua parentcomment no dicionário e, em seguida, armazenar o comentário atualmente processado também no dicionário.

Answer 2

algumas coisas para considerar também ...

1) Quando você diz "tipo como reddit", baseado na posição ou data, você quer dizer o de nível superior ou a coisa toda?

2) Quando você exclui um nó, o que acontece com os ramos? Você re-parent-los? Na minha aplicação, eu estou pensando que os editores vão decidir - ou esconder o nó e exibi-lo como "comentário escondida", juntamente com as crianças visíveis, esconder o comentário e é filhos, ou bombardeá toda a árvore. Re-paternidade deve ser fácil (apenas definir pai do ciranças para o pai do excluído), mas qualquer coisa que envolva toda a árvore parece ser difícil de implementar no banco de dados.

Eu estive olhando para o ltree módulo para PostgreSQL. Ele deve fazer as operações de banco de dados que envolvem partes da árvore um pouco mais rápido. Ele basicamente permite que você configure um campo na tabela que se parece com:

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

No entanto, ele não garante qualquer tipo de integridade referencial por conta própria. Em outras palavras, você pode ter um registro para "Top.Science.Astronomy" sem ter um registro para "Top.Science" ou "Top". Mas o que deixa você fazer é coisas como:

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

ou

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

Se combinado com o "comment_id" tradicional / "parent_id" abordagem usando procedimentos armazenados, eu estou pensando que você pode obter o melhor dos dois mundos. Você pode rapidamente atravessar o comentário árvore no banco de dados usando o seu "caminho" e ainda garantir a integridade referencial via "comment_id" / "parent_id". Eu estou imaginando algo como:

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

A cadeia de caminho para um comentário olhar como ser

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

Assim, um comentário a base da rosca "102" com um comment_id de "1" teria um caminho de:

102.1

E uma criança cuja comment_id é "3" seria:

102.1.3

A algumas crianças de "3" ter ID é de "31" e "54" seria:

102.1.3.31
102.1.3.54

Para ocultar o nó "3" e os seus filhos, você emitir o seguinte:

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

Eu não sei embora - pode adicionar uma sobrecarga desnecessária. Além disso, eu não sei o quão bem ltree mantida é.

Answer 3

Seu projeto atual é basicamente bom para pequenos hierarquias (menos de mil itens)

Se você quiser buscar em um nível certian ou profundidade, adicionar um item de 'nível' para a sua estrutura e computá-lo como parte do save

Se o desempenho for um problema usar um cache decente

Answer 4

Eu adicionaria os seguintes novos campos para a tabel acima:

• thread_id: identificador para todos os comentários anexados a um objeto específico

• Data: a data comentário (permite buscar os comentários em ordem)

• classificação: o comentário rank (permite buscar o comentário encomenda por ranking)

Usando esses campos que você vai ser capaz de:

1. buscar todos os comentários em um fio em um único op
2. comentários de ordem em um fio por data ou classificação

Infelizmente, se você quiser preservar suas consultas DB perto de padrão SQL você terá que recriar a árvore na memória. Alguns bancos de dados estão oferecendo consultas especiais para dados hierárquicos (F. E. Oracle)

./ alex