¿Cómo implemento comentarios encadenados?

StackOverflow https://stackoverflow.com/questions/597882

Pregunta

Estoy desarrollando una aplicación web que admite comentarios encadenados.Necesito la capacidad de reorganizar los comentarios según la cantidad de votos recibidos.(Idéntico a cómo funcionan los comentarios encadenados en reddit)

Me encantaría escuchar las aportaciones de la comunidad SO sobre cómo hacerlo.

¿Cómo debo diseñar el comentarios ¿mesa?Aquí está la estructura que estoy usando ahora:

Comment
    id
    parent_post
    parent_comment
    author
    points

¿Qué cambios se deberían hacer en esta estructura?

¿Cómo debo obtener los detalles de esta tabla para mostrarlos de la manera correcta?(La implementación en cualquier idioma es bienvenida.Sólo quiero saber cómo hacerlo de la mejor manera posible)

¿Cuáles son las cosas que debo tener en cuenta al implementar esta función para que haya menos carga en la CPU/base de datos?

Gracias de antemano.

¿Fue útil?

Solución

El almacenamiento de los árboles en una base de datos es un tema que tiene muchas soluciones diferentes. Depende de si desea recuperar un subjerarquía también (por lo que todos los niños del artículo X) o si lo que desea es tomar todo el conjunto de jerarquías y construir el árbol de forma de O (n) en la memoria usando un diccionario.

Su tabla tiene la ventaja de que se puede recuperar todos los comentarios en un poste en 1 go, filtrando en el parentpost. A medida que ha definido el padre del comentario en el libro de texto de forma / ingenua, tiene que construir el árbol en la memoria (véase más adelante). Si desea obtener el árbol de la base de datos, se necesita una forma diferente para almacenar un árbol: Ver mi descripción de un enfoque basado en el pre-calc aquí: http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID = 17.746 y ThreadID = 3,208 o por usando árboles equilibrados descrito por Celko aquí :

o otro enfoque: http://www.sqlteam.com/article/more-trees-hierarchies -in-sql

Si está obteniendo todo en una jerarquía en la memoria y construir el árbol de ahí, puede ser más eficiente debido al hecho de que la consulta es bastante simple: seleccionar .. de comentario donde ParentPost = @id ORDER BY ASC ParentComment

Después de esa consulta, a construir el árbol en memoria con sólo 1 diccionario que realiza un seguimiento de la tupla CommentID - Comentario. Ahora camina por el conjunto de resultados y construir el árbol sobre la marcha: cada comentario se ejecuta en, usted puede buscar su parentcomment en el diccionario y luego almacenar el comentario procesado actualmente también en ese diccionario.

Otros consejos

Un par de cosas a tener en cuenta también ...?

1) Cuando se dice "género como reddit" basada en el rango o la fecha, ¿te refieres a la de nivel superior o todo el asunto?

2) Cuando se elimina un nodo, lo que ocurre con las ramas? ¿Vuelve a los padres de ellos? En mi aplicación, estoy pensando que los editores decidirán - o bien ocultar el nodo y mostrarlo como "comentario oculto" junto con los niños visibles, ocultar el comentario y de los niños, o bombardear todo el árbol. Re-crianza de los hijos debe ser fácil (acaba de establecer padre de los Chidren a los padres de borrado), pero cualquier cosa que implica a todo el árbol parece ser difícil de implementar en la base de datos.

He estado buscando en el módulo ltree de PostgreSQL. Se debe hacer que las operaciones de base de datos que implican las partes del árbol un poco más rápido. Básicamente le permite configurar un campo en la tabla que se parece a: 

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

Sin embargo, no garantiza ningún tipo de integridad referencial por su cuenta. En otras palabras, se puede tener un registros para "Top.Science.Astronomy" sin tener un registro de "Top.Science" o "superior". Pero lo que sí te deja hacer es cosas como: 

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

Si se combina con el tradicional "comment_id" enfoque / "parent_id" uso de procedimientos almacenados, estoy pensando que puede obtener lo mejor de ambos mundos. Puede atravesar rápidamente el comentario árbol en la base de datos utilizando el "camino" y aún así garantizar la integridad referencial a través de "comment_id" / "parent_id". Estoy 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
);

La cadena camino para una mirada comentario como sea 

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

Así un comentario raíz del hilo "102" con un comment_id de "1" tendría un camino de:

102.1

Y un niño cuya comment_id es "3" sería:

102.1.3

A algunos niños de la identificación del "3" que tienen de "31" y "54" serían: 

102.1.3.31
102.1.3.54

Para ocultar el nodo "3" y sus hijos, que le emite la siguiente: 

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

No sé sin embargo - que podría agregar una sobrecarga innecesaria. Además yo no sé qué tan bien mantenido es ltree.

Su diseño actual es básicamente bien para las pequeñas jerarquías (menos de mil elementos)

Si se desea obtener a nivel certian o profundidad, añadir un elemento de 'nivel' a su estructura y computar como parte de la operación de guardar

Si el rendimiento es un problema utilizar un caché decente

Yo añadiría los siguientes campos nuevos a la tabel arriba:

  • thread_id: identificador para todos los comentarios adjuntos a un objeto específico

  • Fecha: la fecha de comentario (permite ir a buscar los comentarios en orden)

  • rango: el comentario pertinencia (permite ir a buscar el comentario de la orden por ranking)

El uso de estos campos serás capaz de:

  1. Obtener todos los comentarios en un hilo en un solo op
  2. comentarios de la orden en un hilo ya sea por fecha o rango

Desafortunadamente, si desea conservar sus consultas DB cerca del estándar SQL que tendrá que volver a crear el árbol en la memoria. Algunos DBs están ofreciendo consultas especiales para datos jerárquicos (F. E. Oracle)

./ Alex

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top