trew,

модераторам или автору bochkov: плиз, добавьте в тот топик (что по ссылке) решение на переменных с одним parent_id !!! Или ссылку туда на весь топик "массивы в ..."!!!

Ну оговорите его, что "не для слабонервных"... но красиво же как! потеряется же...

labirint,

Тогда задавайте конкретные вопросы по факу... что осталось непонятным. Вполне возможно, что "вам осталось сделать первый шаг". :)

labirint,

это можно считать в проце-дурой, но в том виде как есть - это просто набор запросов к Мускулю, каждый из который завершается ; и они подаются последовательно в одной сессии "подряд":

1. SET @C=...; -- устанавливаем переменную сессии с именем "С" в это значение. @ -- признак сессионной переменной и только. Тут - просто такой комментарий. И только. В целом - не нужно.

2. SELECT ... ; -- запрос. Просто он хитрый и поэтому отформатирован в несколько строк, чтобы было понятней "чего в нём спрашивается" у Мускуля. И только.

3. строка с # -- тоже комментарий. Только с того места, где оно стоит и до конца строки. Ничего больше.

Внутри запроса также используются переменные сессии, но в запросе значения им присваиваются через := и только.

Что делает запрос?
В секции FOM - указано объединение подзапроса с ником 'dummy' и таблички с именем tree.
Как видно, подзапрос тупо присваивает сессионным переменным начальные значения... и всё. Там, в качестве начального значения указано search_num -- типа параметр процедуры... при одиночном запросе, можно просто прописать требуемую константу - идентификатор, как стартовый узел поиска поддерева.
Фсё. Ничего больше в секции from - нету.

Разве что "прибит гвоздиком" (force index(primary key) первичный ключ как пожелание, сканировать записи строго в его последовательности.

В секции Веры сказано "копать до тех пор, пока очередной родитель ещё присутствует в переменной @array". Фсё, тожа.

В секции select указано, что для каждой найденной записи (родитель которой есть в @array, а изначально там исходный узел из подзапроса установки переменных!) отдай как поля:
1. Уровень записи
2. Текущего родителя, а заодно: если предыдущий родитель был другим, то
2.1. удали его из переменной @array
2.2. , запомни текущего на будущее
3. Собственно идент узла (как дитенка), а заодно: если текущий родитель есть в списке, то:
3.1. добавь меня в список возможных родителей (а вдруг у меня есть потомки! -- вот тут-то и создается список проверяемых узлов, связанных с первым, "внезапно" :)
Всё. Ничего больше отдавать не требуется.

Как видим, исходная таблица - тупо сканируется в порядке первичного ключа, который составной от верхнего уровня к листьям и с меньшего родителя к большему. Если кроме первичного, у таблички других ключей нет, то и ладушки. Работать будет.

А вот ежели есть, то не факт: мускуль запросто может "опимизнуть" по другому индексу и порядок сканирования будет нарушен.. со всеми последствиями. Об чём в факе и было указано как существенное ограничение решения, дополнительно.

labirint,

теперь на вопросы внизу поста (а то и так много):

1. level - это тупо номер уровня, +1 к корню на каждом уровне. Поскольку добавляя запись в табличку, вы всегда её привязываете к некоторому узлу, то по факту - уровень новой записи - это уровень родителя+1.

2. Добавить соответствующее условие в часть Веры: И "уровень не больше заданного" как-то так.

3. ?!? а почему нет? Результат - список узлов данного поддерева от заданного узла... а куда и с чем вы его считать будете... пробуйте. Все равно в надзапрос заворачивать...

4. insert .. select() ? почему нет? я - не пгобовал за ненадобностью... но при переносе поддеревьев, возможно и актуально. Дерзайте.

ИМХО есть в факе: запрос оригинальный, работает быстро... но имеет существенные недостатки (отсутствие гарантии выборки строго по индексу)... то есть для очень простых и/или лабораторных испытаний - полезно. А для "боевого применения", я бы выбрал запрос с подселектом. Он значительно медленнее, но зато не страдает фигней.

... хотя, для простых поисков поддеревьев он у меня работает в таком виде... и давно.

labirint,

упс... только сейчас увидел. Сразу на всё:

1.

При создании первичного и единственного составного индекса, автоинкремент там надо отключать. Практика показала, что инкрементировать можно на клиенте кучей разных способов, начиная от ведения таблицы универсального идента... типа uid.
... уже столкнулись.

Нормально ведет, например так:
SELECT destination.* FROM your_table AS destination
JOIN(

# втыкаем сюда это чудо как подзапрос

) AS derived ON derived.child_id = destination.ident
# Where, group by и т.д. дальше по вкусу...

2. Я такой не знаю. Больше того, и форсеиндекс - тоже всего лишь рекомендация... он не всегда прибивает индекс к запросу...

3. "с подселектом" -- там, где-то чуть выше, который определен как запрос Бочкова. Он практически такой же, но на каждом элементе делает подчиненный запрос к таблице для поиска всех потомков, что гарантирует их корректный выбор. Но это значительно дольше.

4. Этот вариант запроса - быстр и корректен, только при наличии составного индекса и его использовании. За всё надо платить.

Снесите автоинкрементный индекс и признак автоинкремента и создайте составной индекс в заданном порядке полей, именно так (level, parent_id, id)... и попробуйте на тестовой табличке... потом попробуйте Бочковский вариант и оцените разницу в скорости... если она вас устраивает - предпочтите бочковский вариант. Он существенно устойчивее. И, только если вам нужна бОльшая скорость реакции - вот тогда, продолжайте экспериментировать дальше с этим вариантом. Особое внимание - на корректность использования индекса (без него может стать неверно, если в таблице записи вставляются не по порядки и/или удаляются со временем).

labirint,

Просмотрел фак ещё раз. Вот тут 13674855 есть же мой вывод о целесообразности деревьев на одном поле parent_id... в конце поста. Перечитайте, сделайте отдельную табличку всех ребер и не мучайтесь. :)

labirint,

обыкновенная таблица связи узла с узлом: "родитель" - "потомок" - "порядок"(если надо) - "уровень"(если надо). Всё.

Каждый новый потомок добавляется ко всем своим родителям сразу (добавляем все ребра к этому потомку для всех уровней дерева)
, что позволяет простым условием "где родитель равен заданному" вытащить всех его потомков и даже рассортировать по уровням и/или по порядку, если дерево - ориентированно.

Позволяет поддерживать практически любые графы, а не только деревья. В общем случае, размер таблицы растет как факториал от числа узлов, но для деревьев, особенно сильно ветвистых (много потомков) и не сильно глубоких (мало подуровней) - может оказаться также компактно как и поля "уровень" и "родитель" в основной таблице (уровень, порядок узла - полезны сами по себе и для других задач).

... а главное, если снабдить родителя и потомка доп. данными о сущностях - можно организовывать в деревья произвольные данные из разных таблиц/сущностей... :)

Как пример:

узел 1 - корень.
Добавляем к нему потомков 2,3: появляются записи 1-2 и 1-3.
Добавляем к узлу 2 потомков 4,5 (третий уровень поддерева): появляются записи: 1-4, 2-4 и 1-5, 2-5
Добавляем записи к узлу 5 (узлы 10,12,15): появляются записи 1-10,1-12,1-15 и 2-10, 2-12, 2-15 и 5-10, 5-12, 5-15.
... то есть добавляем новый узел ко всем родительским вершинам заданного узла (select где заданный = потомку).

можно ваще оформить как отдельную таблицу с классом доступа на клиенте или ХП и гонять деревья независимо от их участников (собственно у себя так и сделал года 2 назад).

labirint,

странно вы его перечитываете. Вот же 13969570 практически полный пример внутренней части процедуры тестирования, которой всё это гонял когда-то. Там и создание таблички, и её наполнение (есть даже вариант псевдослучайного построения деревьев за комментом)... есть и все тестируемые запросы...

"Пгобовали"? :)