Не. Ну суть я понял. Я не понял, как с ним работать. Вот смотри — в тестах я написал функции getTreeByParent_MP и getTreeByParent_FH, которые позволяют одним запросом получить дерево по ID родителя. А как будет выглядеть такая функция для вашего метода? Как будет выглядеть перенос ветки на другое дерево и т.п? Я просто не совсем представляю, как с этим работать. Ну и, тем более, FH не накладывает совершенно никаких ограничений, как я уже говорил. Совершенно никаких.
стыдно признаться, но я не совсем понял, как с этим работать? может, вы напишите статью, где детально распишите этот способ с примерами того, как с ним работать?
в жизни вам часто надо извлекать просто рандомный узел?
Если бы я извлекал не рендомный узел, а какой-то определенный, то меня могли бы обвинить в фальсификации и в том, что я специально выбрал такие числа, на которых более выгоден мой метод. В моих же тестах явно видно — в среднем FH намного быстрее, чем MP
вы меряете производительность только операции select. Как насчет insert/update?
Хорошо. Чуть позже — гляну
Синтетические тесты мало что доказывают, вы бы на сценариях real world потестировали.
Консольный форум, как уже говорилось, использует именно эту систему. У меня там не подключено кеширование и акселераторы, я хостюсь на дешёвом хостинге за 5 баксов. Генерация страницы занимает чуть меньше, чем 0.02 секунды. При этом форум с лёгкостью выдержал ХабраЭффект и некоторое замедление в работе было вызвано не движком, а недостаточно широким каналом. Движок же отработал с лёгкостью.
Более того, товарищ, который навёл меня на эту мысль (Java-прогер с многолетним стажем) утверждает, что в HighLoad'е, с которым он работал — используется именно этот способ и он очень хорошо себя показывает.
DELETE FROM `Elements`
INNER JOIN `ElementsHierarchy` as `Hier`
ON `Hier`.`ElemID` = `Elements`.`ID`
WHERE `Hier`.`ParentID` = {ID} OR `Elements`.`ID` = {ID}
Вставка в статье описана — два-три запроса. Перемещение тоже могу описать. То получится где-то два-три запроса на всю ветку. Но работа будет происходить только над элементами ветки и не придется менять часть структуры, которая не затрагивается, как происходит в NestedSets.
Кстати. Не знаю, хорошо ли это, но при изменении иерархии таблица с данными будет совершенно свободна, то есть затрагиваться не будет.
Cудя по тестам — мне надо 0,3 секунды без кеширования для получения из базы дерева размером 11 тысяч узлов. Сколько с кешированием — прикиньте сами. Вот вам и преимущество этого метода.
Формула недостаточно корретна по той причине, что дерево не растёт вглубь.
на 340 объектов у меня получилось 1252 объекта в таблице иерархии.
если бы дерево расло вглубь так, как указано в вашей формуле, то в MP в каждом пути приходилось бы держать и работать с достаточно длинными строками, и я сомневаюсь, что MP показал бы себя в этом лучше, чем FH
нууу. для меня преимущества — очевидны.
при выборке работаем с числовым индексом, никак не ограничены в уровне вложенности.
поиск определённого узла будет быстрее: WHERE `ParentID` = 1453 быстрее, чем WHERE `Path` LIKE '%.1453.%' и т.п.
а вообще — в Кедах сидит как родной. прям как LeechKraft
Хорошо. Чуть позже — гляну
Консольный форум, как уже говорилось, использует именно эту систему. У меня там не подключено кеширование и акселераторы, я хостюсь на дешёвом хостинге за 5 баксов. Генерация страницы занимает чуть меньше, чем 0.02 секунды. При этом форум с лёгкостью выдержал ХабраЭффект и некоторое замедление в работе было вызвано не движком, а недостаточно широким каналом. Движок же отработал с лёгкостью.
Более того, товарищ, который навёл меня на эту мысль (Java-прогер с многолетним стажем) утверждает, что в HighLoad'е, с которым он работал — используется именно этот способ и он очень хорошо себя показывает.
Кстати. Не знаю, хорошо ли это, но при изменении иерархии таблица с данными будет совершенно свободна, то есть затрагиваться не будет.
&img src=«Ссылка» align=«left» />
&img src=«Ссылка» align=«right» />
habrahabr.ru/blogs/development/46659/
phpclub.ru/faq/Tree/
Про применение FH в php лично я нигде не видел. Ну и почитайте ссылку, что дал tegger деревом выше.
На счёт этого там тоже, кстати сказано.
на 340 объектов у меня получилось 1252 объекта в таблице иерархии.
если бы дерево расло вглубь так, как указано в вашей формуле, то в MP в каждом пути приходилось бы держать и работать с достаточно длинными строками, и я сомневаюсь, что MP показал бы себя в этом лучше, чем FH
при выборке работаем с числовым индексом, никак не ограничены в уровне вложенности.
поиск определённого узла будет быстрее: WHERE `ParentID` = 1453 быстрее, чем WHERE `Path` LIKE '%.1453.%' и т.п.