На самом деле, мне лично смешивание Materialized Path и Adjacency List при использовании ltree представляется сомнительным решением, особенно учитывая то, что в большинстве случаем материализованный путь составляется из ID узлов, и ID родителя получить не представляется сложной задачей. Тем не менее, определенные плюсы от этого есть
ltree является дополнением PostgreSQL и входит в пакет contrib, поэтому изначально оно не включено в стандартный пакет для *nix систем
На первый взгляд управление деревом Adjacency List довольно простое, но эта простота, зачастую приводит к определенным проблемам, так очень просто, можно назначить подчинение первого узла второму, а второго первому, что может привести к бесконечному зацикливанию при выборе дерева, можно назначить родителем узла несуществующий ID и тогда ветка полностью выпадет из дерева.
Метод хранения древовидных структур данных Adjacency List один из самых простых в понимании, так как узел включает прямую связь с родителем и не перенасыщен избыточными данными.
Как удобно делать выборки из деревьев типа Nested Sets, и как не удобно им управлять. Как удобно управлять деревьями типа id->parent_id, но как не удобно и накладно использовать рекурсии при выборках.
В данной статье рассматриваем, а как, собственно, можно управлять деревьями Nested Sets
Прежде чем начинать работать с деревом, что бы линий раз не наступать на «грабли», определим основные правила
Одним из методов хранения древовидных структур является Nested Sets (Вложенные множества).
Прежде всего посмотрим как выглядят деревья Nested Sets, как они организованы и в чем удобство их использования.
Поддержка — это когда у нас возникает техническая
проблема с существующей системой,
и вам необходимо некоторое руководство