Не нравятся результаты поиска? Попробуйте другой поиск!
DLE FAQ » Все вопросы » Общие вопросы » Древовидные комментарии - сортировка, навигация, метод хранения данных..?

Древовидные комментарии - сортировка, навигация, метод хранения данных..?


     24.04.2016    Все вопросы » Общие вопросы    2267

вопрос
Итак. по сабжу - проводил некоторое исследование по дереву комментов. Подведу только итоги.
Есть несколько методов хранения данных: смежные вершины (стандартное дерево дле), вложенное множество (как я понял используется тут - модуль от сандера), материализованный путь (пока нет реализаций), ссылочная структура. Преимущества и производительность можно посмотреть в гугле. Но лично я считаю если использовать хранение данных вида новость - дерево комментариев в отдельных таблицах - то надо делать через смежные вершины, если в одной таблице - то вложенное множество. Однако, если мы сталкиваемся с навигацией - то везде облом - нет оптимальной реализации - в смежных вершинах - её нет в принципе, во вложенном множестве - можно реализовать выбором по level=0 и составлением веток, в материализованных путях - так же, но вывод без индекса.

Так же при выводе дерева интересна сортировка - от старых к новым или от новых к старым. Логичен вывод от старых к новым как тут, однако если новости например несколько лет и она часто комментируется - такая сортировка не удачна, но делать обратную - не удобно для чтения. Как сделать лучше и адекватно?

Итак подходим к вопросам. Нужна ли навигация и каким образом сортировать комменты для нескольких случаев - Комментируется новость несколько лет и нечастое ответвление (1), частое (2), новость быстро забывается и множество веток (3. например хабр) и мало веток (4, как тут).

Ответа пока нет


5 комментариев

ПафНутиЙ
Админ

ПафНутиЙ - 24 апреля 2016 20:45 -

Исходя из практики использования дерева комментариев в DLE могу точно сказать, что навигация не нужна т.к. адекватное её построение очень непростая тема и очень часто она вообще не нужна т.к. комментариев не набирается и на одну страницу.
Если же отталкиваться от необходимости построения навигации, то я бы выбрал "стиль" комментариев из фейсбука, когда по умолчанию ответы на первого родителя скрыты. Тогда для навигации следует отбирать только нулевой уровень.

По хранению лучше всё же nested sets т.к. при чтении (а это самая частая операция) эта структура даёт наибольший выигрыш в производительности, а хранить комменты для каждой новости в своей таблице (если правильно понял смысл) — это совсем индивидуальный случай.

Сортировка - это сугубо индивидуальная штука, но при древовидном выводе единственный логичный вариант — от старых к новым, иначе дерево визуально будет не совсем адекватное, когда родители идут вверх, а потомки вниз smile

Так же, если ты заметил, тут есть такая полезная штука, которая подсвечивает новые комментарии с твоего последнего захода в вопрос. Это очень эффективное решение проблемы "что нового появилось в посте с моего последнего захода сюда", не так как на хабре, но всё же лучше, чем ничего.

Каков вопрос - таков и ответ. Просто помните об этом.

nowheremany
Эксперт

nowheremany - 24 апреля 2016 21:15 -


Цитата: ПафНутиЙ
По хранению лучше всё же nested sets т.к. при чтении

Если мы не используем навигацию, то получаем все комменты. Построение через вложенное множество или nested sets - конкретно для этого случая - избыточно и не удачно. Т. к. проще использовать php для этого, а не базу.
Вообще nested sets очень не популярное решение и слишком специфичное. если что-то случится с транзакцией - упадёт все дерево и его перестроить вряд ли получится. Оно идеально подойдет для частого чтения отдельной ветки при минимальном его изменении, т. к. при изменении идёт перестроение всего дерева.

У меня были ситуации когда комментов на 30 страниц без дерева - дерево нужно присобачить, но выводить 30*50 комментов для того что бы посмотреть новые - расточительно и для юзера не интересно

Прикрепил анализ чтения при разом методе хранения
А так же добавление, изменение и удаление элемента

Благодарность принимаю тут Связь

ПафНутиЙ
Админ

ПафНутиЙ - 24 апреля 2016 22:25 -

Ну по графикам видно преимущество nested sets кругом.
На практике было только пару раз, когда я нечаянно удалял не ту ветку и по цепочке удалялись все комментарии. Неприятно, но это уче косяк конкретного пользователя, а не функционала. Глюков функционала ни разу не видел, но тут не очень часто добавляются комментарии в принципе.

Цитата: nowheremany
У меня были ситуации когда комментов на 30 страниц без дерева - дерево нужно присобачить, но выводить 30*50 комментов для того что бы посмотреть новые - расточительно и для юзера не интересно

Тут один выход — строить навигацию по нулевому уровню.

Каков вопрос - таков и ответ. Просто помните об этом.

nowheremany
Эксперт

nowheremany - 24 апреля 2016 22:42 -


По графикам - это время выполнения )) т. е. добавление в ветку с 100000 коментов 1,5 минуты занимает )))

во вложении схема идеальна для NS

Благодарность принимаю тут Связь

nowheremany
Эксперт

nowheremany - 24 апреля 2016 21:29 -

Ещё есть сортировка как в вк - 0 уровень от новых к старому, и 1 и ниже - от старых к новым. Для варианта когда комментов на 30 страниц будет выходом из ситуации

Благодарность принимаю тут Связь

Чтобы комментировать - войдите или зарегистрируйтесь на сайте

Похожие вопросы

наверх