Какой лучший способ разделения вложенных обсуждений на несколько страниц - для веб-приложения?

Question

Я проектирую многопоточное отображение сообщений для приложения PHP / MySQL - например, комментариев на Slashdot или Youtube - и мне интересно, как мне поступить, упорядочив комментарии и разделив их на страницы, чтобы вы могли иметь, скажем, 20 комментариев на страницу, но все же они вложены.

Комментарии в моем приложении могут быть вложенными неограниченными уровнями, и эта структура представлена ​​с использованием того, что я считаю таблицей отношений смежности, отдельной таблицей, содержащей строку для каждой пары, имеющей какие-либо отношения восходящего / дочернего элементов. В этой таблице отношений есть CHILDID, PARENTID и LEVEL, где уровень 2 означает «прадедушка» и т. Д.

Мой вопрос касается как удобства использования для конечного пользователя, так и практичности построения эффективного запроса к БД. Я рассмотрел эти варианты:

• Разделение результатов на страницы по дате, независимо от положения в дереве, чтобы все комментарии в определенном диапазоне дат отображались вместе, даже если они не отображаются вместе с родителями. Любой комментарий, который был опубликован в то же время, что и его родитель, будет отображаться на той же странице, и в этих случаях мы можем отображать их «вложенными», но будут комментарии, которые осиротели от их родителей. Это, вероятно, приемлемо - так все и делается в комментариях YouTube - комментарий, сделанный намного позже, чем его родитель, не будет отображаться на той же странице, что и его родитель (если родитель не на последней странице), а вместо этого появится с другие новейшие комментарии.

• Извлечение узлов по порядку, как если бы вы проходили по дереву. Это отдает приоритет древовидной структуре, а не дате, хотя братья и сестры могут быть отсортированы по дате. Преимущество этого заключается в том, что ответы всегда помещаются вместе с их родителем (комментарий, на который они отвечают), даже если этот родитель является числом страниц из последних комментариев. Вот как это делается в таких приложениях, как блог icanhascheezburger. Мне не нравятся некоторые вещи об этом, как то, как у всех возникает желание добавить ответ на самую большую ветвь дерева.

• Третий вариант - делать то, что делает Slashdot, когда он не разделяет комментарии на страницы, но имеет одно большое дерево - для того, чтобы сохранить размер страницы, управляемый, вместо этого он начинает отбирать комментарии с низким рейтингом.

Я думаю, что первым будет самый простой запрос к БД с учетом моей таблицы отношений, но он будет открыт для других идей.

Некоторые такие системы всех трех типов каким-то образом ограничивают уровень вложенности - это достаточно просто сделать, если мы пройдем по уровням X, все остальное можно объединить, как если бы они были братьями и сестрами. Например, комментарии YouTube отображаются только на одном уровне. Другие системы иногда говорят «превышен уровень вложенности» после 5 или около того уровней.

Answer 1

Я предполагаю, что причина, по которой вы вообще хотите использовать вложенные комментарии, заключается в том, что ваши пользователи, как правило, хотят читать по одной интересующей ветке за раз. То есть у вас есть основания полагать, что пользователи будут создавать потоки последовательных цепочек мышления, и / или то, что обсуждается в одном потоке, заинтересует некоторых пользователей, но не других.

Если это так, я не знаю, почему вы захотите произвольно разделить поток по страницам по дате (вариант 1). Использование одной страницы с отбраковкой комментариев с низким рейтингом (вариант 3) выглядит немного жестко и может отговорить пользователей от публикации комментариев. Это может быть хорошо, если у вас есть такая аудитория, как SlashDot, но это может быть нежелательно для сайтов с более типичным уровнем посещаемости.

Возможно, у вас может быть что-то вроде Варианта 2 со всеми потоками на одной странице, но если поток начинает становиться слишком длинным, он сворачивается в одну ссылку, которая ведет пользователя на страницу, посвященную этому потоку. В качестве альтернативы, длинные темы могут быть сокращены, чтобы просто отображать свои сюжетные линии и авторов, каждый из которых, в свою очередь, ссылается на соответствующее место на специальной странице для темы.

Я подозреваю, что склонность пользователей публиковать нерелевантные комментарии в самой большой ветке - это результат того, что пользователи не хотят, чтобы их прокручивали, чтобы найти конец цепочки или найти ветку, которая более подходит. Автоматически сжимая длинные потоки, оставляя корень всех потоков, отображаемых на одной странице, управляемой длины, пользователи могут легко сканировать интересующий поток и добавлять к нему при желании.

Answer 2

Я думаю, что вам нужно хранить иерархические данные в базе данных. Вы должны начать с этой статьи: Статья на сайте Статья на сайте MySQL