Корневые элементы в Materialized Path

ivanov77

Новичок
Приветствую.
В Materialized Path смотрю в реализациях постоянно проектируют как тут :
То есть любой комментарий, который находится на первом уровне, автоматически считается корневым для своего дерева.
Т.е. для дерева
Код:
id | name
-------------------
1  | comment_1
2  |   comment_1_1
3  |     comment_1_1_1
4  |   comment_1_2
5  | comment_2
6  |     comment_2_1
7  |     comment_2_2
8  | comment_3
comment_1, comment_2, comment_3 будут считаться корневыми элементами, т.е. проектируется как будто в таблице много разных деревьев.

Но разве это отражает реальность? Дерево то одно и comment_1, comment_2, comment_3 - первые потомки корневого элемента(которого просто нет в таблице), и этих потомков также касаются все правила узлов соседей, а не корней разных деревьев.
Разве не смущают вот это все ->roots() в апи и $node11->root (у каждой ветки который получится свой) ?, смотрю для примера тут
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
давай начнем с того, что авторов статьи из evileg здесь нет

по сути, вопрос я не понимаю
дерево - это структура в памяти, в php это реализуется массивом или объектом,
любой узел может быть выделен в самостоятельное дерево, по желанию разработчика
иногда это делается по нефункциональному требованию - например, если полный набор данных занимает в памяти несколько гигабайт, имеет смысл обрабатывать части как самостоятельные деревья
 

ivanov77

Новичок
Ссылка на теорию чтобы говорить об одном и том же.

Вопрос не про представление деревьев в памяти, а об определенном методе хранения дерева в реляционной БД.

Одно Дерево типа как, следуя их подходу, сохранили, а у дерева, в теории если почитать что такое дерево, должен быть один корневой элемент.
А в этих реализациях спроектировано и проталкивается так что для
comment_1_1 корневым является comment_1
а для
comment_2_1 корневым является comment_2

Хотя это все в реале то узлы одного дерева
 

ivanov77

Новичок
то есть лес из деревьев в реальности не существует?
Существует.
Но вы правильно заметили что это уже будет лес, а не одно дерево.
А ведь вся эта возня затевалась чтобы связать сущности иерархической связью в одно дерево.
 

Фанат

oncle terrible
Команда форума
А вот этот уже действительно не имеет ничего общего с реальностью.
Ты себе вбил в голову одно дерево, и теперь и теперь пристаешь ко всем с вопросом, почему реальность не соответствует твоим фантазиям
 

WMix

герр M:)ller
Партнер клуба
создай еще один узел comment и вложи comment_1, _2 и _3 в него, и будет тебе одно дерево
 

ivanov77

Новичок
А вот этот уже действительно не имеет ничего общего с реальностью.
Ты себе вбил в голову одно дерево,
Ну стоит же задача сохранения дерева в БД. Поэтому и речь идет об одном дереве. В Nested Sets когда проектирует дерево, оно одно, оно не разбивается на много других, там такое даже не получится.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
дорогой мой, от нас ты чего хочешь? хочешь одно дерево - делай одно, к нам какой вопрос?
 

Фанат

oncle terrible
Команда форума
В Nested Sets когда проектирует дерево, оно одно, оно не разбивается на много других, там такое даже не получится.
ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха ха
ха ха
для построения дерева на php
дерево в материализованном пути строится одним тупым запросом с сортировкой по пути. И выводится еще более тупым циклом. Именно в этом вся суть, смысл, достоинства и недостатки материализации.
Зачем тебе все эти ->roots - загадка.
 

ivanov77

Новичок
дерево в материализованном пути строится одним тупым запросом с сортировкой по пути. И выводится еще более тупым циклом.
На практике это все так просто не работает 🙂
Например при выводе этим тупым циклом не решается ситуация когда вывел родителя, затем начинаешь выводить его детей, а у них всех пометка "Не показывать", и получается что такого родителя выводить не стоило.

Пример для чего мне это надо - в проектировании сервиса, который построит нужное мне дерево или поддерево.
На вход он принимает какой то узел, по нему смотрит что нужно за SQL запрос сформировать для вывода всего поддерева этого узла. Для любого узла дерева это сработает на ура, а для того чтобы сработало для всего дерева, нужно в сервис передать вот этот один корень.
 

AnrDaemon

Продвинутый новичок
Почему не стоило, если у родителя нет этой отметки?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
бинарные деревья состоят из одноранговых элементов, все узлы равны
на форуме разделы - дерево, записи в разделах - не элементы дерева, а связанные объекты
логика "выводить/не выводить" с деревом не связана, если нужна сложная логика - или не используй дерево, или обрабатывай дополнительно итерацией по элементам

а вот как сделать, чтобы и дерево, и обработка, и быстро - это и есть квалификация, но это уже не теория
 

Фанат

oncle terrible
Команда форума
который построит нужное мне дерево или поддерево.
Ушам своим не верю!
Наш упертый ортодокс произнес запрещенное слово!
Так и совсем до ереси скатиться недолго, и отбросить приставку "под". И что тогда останется от теории о единственном и неделмом дереве?
для того чтобы сработало для всего дерева, нужно в сервис передать вот этот один корень.
Ну так это проблема конкретного сервиса, а не материализованного пути, как архитектуры
 
Сверху