Comments 16
Может я скажу глупость,
но почему бы не пользоваться «Nested set model» — en.wikipedia.org/wiki/Nested_set_model
но почему бы не пользоваться «Nested set model» — en.wikipedia.org/wiki/Nested_set_model
не всегда удобно…
сразу примеры. когда «не всегда»? :-)
Я писал как-то набор процедур для mysql для работы с nested sets. Посмотреть можно здесь: 89.249.21.130/mysql_nested_sets.sql
Если нужны будут пояснения — могу написать подробно.
Если нужны будут пояснения — могу написать подробно.
а почему MSSQL не упомянули про встроенные средства отбора… может они и не по деревьям но все же…
есть конструкция with 'имя курсора' as {}
есть конструкция with 'имя курсора' as {}
зачем сложная РЕКУРСИВНАЯ процедура, если можно вполне целостность поля поддерживать и средствами триггеров.
далее:
далее:
ёмаё
1) естественное ограничение на вложенность иерархии.
никто не заставляет искать по целому полю. первые N уровней (где N > 50) вполне отсекут лишнее в любой даже самой глубокой иерархии
2) серьезнная нагрузка на сеть
запрос выполняется на mysql-сервере. откуда у нас появился оверхед на сеть при выполнении 1 (одного) запроса?
а пункт 4 из минусов и вовсе вторит пункту 2 (ну это вероятно для усиления трагичности). да и сам пункт вполне разруливается триггером.
«ограничение чем-нибудь типа like %...%.»
а вы приведите пример типовых задач, которые решаются при использовании вами дерева.
задачи вроде: получить всех потомков выполняется за 1 быстрый запрос, получить всех предков — 2 быстрых запроса (быстрые, это значит используют индекс)
1) естественное ограничение на вложенность иерархии.
никто не заставляет искать по целому полю. первые N уровней (где N > 50) вполне отсекут лишнее в любой даже самой глубокой иерархии
2) серьезнная нагрузка на сеть
запрос выполняется на mysql-сервере. откуда у нас появился оверхед на сеть при выполнении 1 (одного) запроса?
а пункт 4 из минусов и вовсе вторит пункту 2 (ну это вероятно для усиления трагичности). да и сам пункт вполне разруливается триггером.
«ограничение чем-нибудь типа like %...%.»
а вы приведите пример типовых задач, которые решаются при использовании вами дерева.
задачи вроде: получить всех потомков выполняется за 1 быстрый запрос, получить всех предков — 2 быстрых запроса (быстрые, это значит используют индекс)
ps:
«Времени на его реализацию как всегда не было.»
да уж, времени на составление хука в пхп, вызывающегося при изменении стрктуры, на пару с 1 примитивным запросом (или триггера, см. выше) не было. зато было время на написание рекурсивной процедуры в 50+ строк :-) хехе
«Времени на его реализацию как всегда не было.»
да уж, времени на составление хука в пхп, вызывающегося при изменении стрктуры, на пару с 1 примитивным запросом (или триггера, см. выше) не было. зато было время на написание рекурсивной процедуры в 50+ строк :-) хехе
Автору крайне рекомендую почитать Managing Hierarchical Data in MySQL
Автору большое спасибо за пост! правда пришлось немного поколдовать с кодом.
Во-первых опечатка в запросе создания временной таблицы(забыли про уровень).
Правильный запрос такой:
Во-вторых на моем дереве (глубина=3) постоянно не хватало max_sp_recursion_depth
В коде процедуры заменил:
Во-первых опечатка в запросе создания временной таблицы(забыли про уровень).
Правильный запрос такой:
CREATE TEMPORARY TABLE tmp__index(id int,pid int ,rid int, level int);
Во-вторых на моем дереве (глубина=3) постоянно не хватало max_sp_recursion_depth
В коде процедуры заменил:
IF zlevel<=0 THEN
/** число наобум */
SET max_sp_recursion_depth= 15;
ELSE
SET max_sp_recursion_depth= zlevel+1;
END IF;
на
SET max_sp_recursion_depth= 15;
и заработало.
В-третьих, непонятно зачем делается запрос с Join select c.* from catalog as c join tmp__index as t on t.rid=c.id если можно взять сразу всё select'ом в начале процедуры и записать это во временную таблицу, а потом вернуть.
После этих правок всё заработало. Еще раз большое спасибо!
Sign up to leave a comment.
Задача отображения деревьев в MySql. Способ отображения на хранимых процедурах