Пакет для фреймворка Laravel, который позволяет организовать управление древовидными комментариями. Используется симбиоз двух методов хранения иерархических структур — «Closure Table» и «Adjacency List».
Git-репозиторий
Требования
- Фреймворк Laravel 5.7 или более новый.
- Версия PHP минимум 7.3.
Преимущества
Использование симбиоза методов хранения иерархических структур «Closure Table» и «Adjacency List» позволяет решить 2 важные проблемы, с которыми приходится сталкиваться при работе c реляционными СУБД:
- Отсутсвие возможности без рекурсии извлечь одним простым запросом произвольную часть иерархии.
- Низкую производительность при извлечении древовидной структуры из базы данных.
Совместное применение методов «Closure Table» и «Adjacency List» позволяет:
- Минимизировать количество запросов к базе данных. Для извлечения ветки комментариев достаточно одного запроса.
- Обеспечить высокую производительность. Запросы на чтение к базе данных простые и скорость выборки узлов иерархии практически не снижаться при увеличении объёма данных.
- Хранить текст комментариев и иерархическую структуру отдельно друг от друга, в двух таблицах.
- Контролировать глубину вложенности комментариев. Уровень узлов иерархии всегда известен, нет необходимости получать информацию о предках узла, чтобы определить уровень.
- Гарантировать целостность данных иерархии.
- Работать с древовидными структурами без рекурсивных запросов. Не во всех СУБД есть поддержка рекурсивных запросов, кроме этого, данный механизм недостаточно эффективный и имеет ряд ограничений.
Рассмотрим известные способы хранения и работы с деревьями. Их не так уж и много.
Особенность метода «Adjacency List», заключается в том, что без поддержки рекурсивных запросов СУБД извлечь одним простым запросом произвольную часть иерархии невозможно.
Метод «Path Enumeration», или как его ещё называют «Materialized Path» неэффективен из-за низкой производительности SQL-запросов select, так как предполагается использование оператора LIKE и поиск по шаблонам вида: '1/2/3/4%'. Хранение некого множества в виде строки с разделителями, едва ли уместно в мире реляционных баз данных.
Самый интересный паттерн для работы с древовидными структурами — «Nested Sets». Он вполне может быть использован для хранения иерархических структур, но его реализация сложная и он не обеспечивает гарантию целостности данных. Ошибка при вставке нового элемента в иерархию или при переносе поддерева из одного места в другое может создать большие проблемы. Необходимость пересчёта и изменения значений части левых и правых индексов элементов поддерева при добавлении нового элемента является существенным недостатком «Nested Sets».
Последний метод «Closure Table» мог бы стать лучшим выбором, если бы не одно «но» — отсутствие простого способа построить отсортированное дерево из получаемого запросом плоского списка связей.
Совместное использование «Closure Table» и «Adjacency List» позволяет объединить преимущества этим методов и избавится от недостатков.
Пример схемы связей элементов дерева «Closure Table»:
В методе «Closure Table» каждый узел иерархии хранит ссылки на всех своих предков и на самого себя.
«Adjacency List» предполагает обязательное хранение информации о смежных узлах дерева и опционально уровень каждого узла.
Объединив специфику хранения информации этих двух методов, мы получим все необходимые данные для того, чтобы извлекать одним запросом требуемую часть иерархии и строить отсортированное дерево.
Установка
1. Перейдите в рабочий каталог вашего проекта на Laravel и выполните команду:
2. Добавьте в файл конфигурации приложения config/app.php сервис-провайдер. Строку указанную ниже следует внести в массив 'providers'.
3. Выполните команду, которая скопирует файл конфигурации closure-table-comments.php в каталог config вашего приложения:
После выполнения данной команды, в файле config/closure-table-comments.php вы можете изменить название базы данных и таблиц. Если это необходимо, то скорректируйте параметры конфигурации, прежде чем двигаться дальше.
4. Если ваши файлы конфигурации кешируется, то выполнить в команду:
5. Теперь создадим таблицы в базе данных. Выполните в консоли команду, которая запустит выполнение миграций:
В результате будут созданы 2 таблицы в вашей СУБД.
Использование
Каждый комментарий может относиться к определённому предмету и иметь ссылку на автора, который его написал.
Например, если требуется организовать обсуждение статьи на новостном сайте, то уникальный целочисленный идентификатор сущности «Статья» следует использовать в качестве указания на принадлежность комментариев к обсуждаемому предмету, а целочисленный идентификатор пользователя будет указывать на автора комментария.
Посмотрите внимательно на модели Comment и StructureTree.
subject_id — целочисленный идентификатор сущности «Статья». Может иметь значение NULL.
Если subject_id равняется NULL, то комментарий не будет относиться к какому-либо предмету.
user_id — целочисленный идентификатор сущности «Автор статьи». Может иметь значение NULL.
Если user_id равняется NULL, то комментарий не будет принадлежать какому-либо автору. Такие комментарии можно считать анонимными.
1. Создание корневого нового комментария.
Предположим, у нас есть сущность «Статья» с уникальным номером 5636 и пользователь с уникальным идентификатором 7 решил оставить комментарий к статье.
В базе данных будет создан комментарий с уникальным идентификатором $id, он будет принадлежать статье с кодом 5636. Автором комментария будет пользователь с идентификатором 7.
2. Ответ на комментарий, который был написан ранее.
Предположим, у нас есть сущность «Статья» с уникальным номером 5636 и пользователь с уникальным идентификатором 43 решил ответить на ранее написанный другим пользователем комментарий к статье.
Для этого нам нужно знать идентификатор комментария (или уникальный номер узла в древовидной иерархии комментариев Node), на который пользователь хочет написать ответ. Предположим, что уникальный идентификатор комментария равен 1.
В базе данных будет создан новый комментарий с уникальным идентификатором $id, он будет принадлежать статье с идентификатором 5636. Автором комментария будет пользователь с идентификатором 43.
Здесь важно то, что новый добавленный комментарий будет связан с родительским комментарием (с идентификатором равным 1). Кроме связи, уровень (level) нового комментария будет на единицу больше, чем уровень родительского комментария.
3. Редактирование текста комментария.
Для внесения изменения в текст комментарий нужно знать его уникальный идентификатор.
Если изменить комментарий удалось, то $res будет иметь значение true.
4. Проверка существования комментария
Вы можете узнать существует ли комментарий (узел в иерархии) по его уникальному идентификатору.
Если комментарий с уникальным идентификатором в древовидной структуре есть, то переменная $res будет равняться true.
5. Получение комментария (узла в иерархии) по уникальному идентификатору
Предположим, что мы хотим получить объект Node по уникальному идентификатору, который равен 2.
В случае, если комментарий с уникальным идентификатором 2 существует, метод getNode вернёт объект Node. Объект Node будет содержать информацию об узле иерархии комментариев.
6. Получение отсортированной ветки комментариев
Предположим у нас есть статья с уникальным идентификатором 5636, к этой статье разные пользователи написали комментарии. Некоторые комментаторы начали дискуссию между собой. То есть, у нас образовалась древовидная структура комментариев.
Но дискуссия возможна только, если мы сможем корректно визуализировать структуру комментариев. Иначе пользователи просто не смогут общаться между собой. Для этого необходимо сформировать список отсортированных комментариев (узлов древовидной структуры). При этом, в отсортированном списке узлов должен быть указан уровнь каждого узла, а так же идентификатор узла родителя.
Для решения данной задачи следует использовать метод getTreeBranch.
В результате мы получим коллекцию объектов Node.
Если нужно получить узлы иерархии комментариев начиная с узла с определённым идентификатором, то в метод getTreeBranch следует передать значение этого идентификатора.
Мы получим коллекцию объектов всех узлов иерархии начиная с узла 2.
7. Получение массива древовидной иерархии
Получить массив дерева комментариев можно при помощи метода getTreeBranchArray.
Если необходимо получить ветку комментариев, которая должна начинаться с определённого узла, то в метод getTreeBranchArray следует передать идентификатор этого узла иерархии.
8. Получение идентификаторов ветки комментариев
Предположим, мы хотим получить массив уникальных идентификаторов всех узлов ветки комментариев начиная с узла с идентификатором 23.
В результате мы получим массив $ids содержащий идентификаторы узлов ветки комментариев.
9.Получение уровня узла по уникальному идентификатору
Предположим, нам нужно узнать уровень узла 23 в иерархии, но извлекать объект Node методом getNode мы не хотим, так как нам нужна лишь информация об уровне. Чтобы это сделать, следует воспользоваться методом getLevel.
10. Удаление узла иерархии (листа) или ветки древовидной иерархии комментариев
Если нам нужно удалить ветку комментариев или только один последний комментарий в иерархии (лист в дереве комментариев), то это можно сделать при помощи метода delete.
Метод delete получает уникальный идентификатор узла и удаляет все комментарии, начиная с узла, идентификатор которого был передан этому методу.
В примере ниже мы удаляем узел 64 и всех его потомков, если они есть.
Будьте осторожны, удалённые комментарии восстановить невозможно.
Критика «Closure Table»
Шаблон «Closure Table» часто критикуют за то, что необходимо хранить в базе данных связи каждого элемента дерева со всеми его предками, а так же ссылку каждого элемента на самого себя. Чем глубже в иерархии располагается элемент, тем больше записей в таблице необходимо сделать. Очевидно, что добавление новых элементов в конец глубокой древовидной иерархии будет менее эффективным, чем вставка элементов вблизи корня дерева.
Кроме этого, стоит отметить, что для хранения деревьев метод «Closure Table» требует больше места в базе данных, чем любой другой метод.
Для того чтобы объективно оценить значимость этих замечаний, их следует рассматривать в контексте специфики реального проекта.
Например, снижение производительности при добавлении нового элемента на двухвостый или тысячный уровень может быть незначительным или некритичным для работы приложения, или же, что ещё более вероятно, такая ситуация вовсе никогда не произойдёт.
Как правило, нет необходимости в иерархических структурах большой вложенности. Кроме этого, в большинстве случаев, принципиальным параметром является скорость извлечения данных, а не записи.
Объём дискового пространства, который может потребовать структура дерева едва ли стоит учитывать, так как другие потребители этого ресурса намного более значимые, например логирование посетителей сайта.