Forum Webscript.Ru
Общие => Базы данных => Тема начата: Phoinix от 10 Сентября 2004, 12:53:40
-
Сама статья находится по адресу:
http://www.webscript.ru/stories/04/09/01/8197045
Вообщем я смотрю у народа начали возникать вопросы по поводу организации деревьев Nested Sets, поэтому я думаю все таки поместить обсуждение суда, так как в комментах, это несколько не удобно...
Последний комментарий
Dmitry Zlygin пишет 09.09.2004 @ 19:13
Не пинайте сильно, но из статьи не понял сути организации такого дерева. Что за поля такие, на что ссылаются? Что такое правый ключ, левый ключ, что они обозначают? Зачем применяется уровень? Статья явно рассчитана на тех, кто уже знает Nested Sets. Я не знаю, и, думаю, что не один в своем незнании. Man что?
Нормальные FOREIGN KEYS определить нельзя, хотя бы в терминах распространенного PostgreSQL?
Как сейчас есть - одна из самый бестолковых статей на сайте (не в обиду будет сказано).
1. "Что за поля такие, на что ссылаются?" - Обычные поля тип - INT(), никуда не ссылаются ;).
2. В них (правый и левый ключ) хранится информация о дереве. Так же по ним выбираются диапазоны дерева, и сортировка (по левому ключу);
3. Уровень применяется для удобства, что бы видеть на каком уровне находится узел, а так же для упрошения выбора родительского и подчиненных узлов;
4. Статья явно расчитана на тех, кто хоть когда имел опыт работы с деревьями, первый раздел посвящен именно организации, если информации там не хватает, то: man Google, man yandex;
5. Что значит нормальные FOREIGN KEYS? Есть еще и не нормальные ;)? И собсвенно не понял этой фразы. На протяжении всей статьи мы работаем с одной таблицей, и куда прилепить FOREING KEYS в статье, ума не приложу... Если же ты хочешь прицепить еще одну таблицу, то вперед, поле ID в дереве которое PRIMARY KEY никто не отменял...
[OFF]А вот насчет бестолковости, я бы не был столь критичен... Вы собственно кто? что бы делать такие утверждения? Очередной Победитель региональной олимпиады по программированию???[/OFF]
P.S. Собственно, все комментарии и вопросы по статье наверно лучше выкладывать сюда...
-
Phoinix не заморачивайся. Парень просто не в теме и ему обидно стало за свою недалекость. Когда возникнет задача - откопает и еще спасибо скажет.
-
NeoNox
Да нет... просто сама по себе тема интересная, я сам некоторое время использовал принцип построения дерева:
| id | paretn_id | name | ... |
И имел довольно большой гемморой, пока случайно не натолкнулся на Nested Sets... Хотя решение было написано для PHP, перевести на Perl было не долго...
Но мне не понравился класс PHP cdbtree, в части переноса узлов. Поэтому я сделал свое решение, которое позволяет 1 запросом перемещать узел в любую точку дерева...
Интересен факт, что мои знакомые программисты, которые не используют подобный принцип построения деревьев, видят в нем удобство, но не могут перейти в силу того, что прийдется изменять очень много своих наработок. Поэтому хочется что бы начинающие пользователи все-таки поняли идею, и применяли её в дальнейшем, и меньше наступали на грабли. А то что это им прийдется "вдалбливать", я думаю, ты знаешь лучше меня... ;)
-
Вот подробная и понятная статья:
http://www.pyaticom.ru/article/004/
-
APL
[OFF]Вообще-то эта статья та же самая.[/OFF]
-
APL Croaker
[OFF]:D:D:D
Это точно... на неё я даже ссылку с основного сайта не сделал... т.к. нет соответсвующего раздела, эта ссылка предназначалась для rusdoc...[/OFF]
-
Сорри, не смотрел...
-
Насчет недалекости 2 NeoNox - извините, всех делов не знаем, неужели благородный дон настолько крут, что знает все и вся в программировании?
Спасибо за плохо написанную/скомпонованную статью не вижу смысла говорить. Вы так и не объяснили смысла полей left и right.
Речь шла о том, что неплохо бы написать в статье небольшое теоретическое введение, или сделать по крайней мере ссылку на статью с теорией.
Насчет деревьев - работали, старым дедовским методом смежных вершин. Увидел новое слово - заинтересовался - а тут такая фигня, типа, вы это все давно знаете. Этакий снобизм. Я думаю, не все читатели сайта в курсе ВСЕХ потенциально применимых в программировании технологий.
Насчет foreign key - разобрался, в nested sets они действительно не нужны. Насчет того, что в случае одной таблицы не может быть foreign key - это вы лихо... реализация дерева методом смежных вершин:
create table test(
name varchar(10) not null primary key,
parent varchar(10) null references test(name)
);
чем же, по-вашему, является поле parent в примере выше?
По поводу статьи: " Квадратами обозначены узлы дерева, синие цифры в верхнем правом и верхнем левом углах узла - уровень и уникальный идентификатор соответственно, а красные цифры в нижних углах - это левый и правый ключ. Именно в этих двух цифрах - левом и правом ключе заложена вся информация о дереве." Именно в этой фразе отражена суть того, что мне не понравилось :-\\ Во втором предложении смысла - ноль целых ноль десятых.
Как это описывается хорошо/понятно - можно посмотреть на:
http://www.sql.ru/articles/mssql/01091502TreesInSQL.shtml
-
Поэтому хочется что бы начинающие пользователи все-таки поняли идею, и применяли её в дальнейшем, и меньше наступали на грабли. А то что это им прийдется "вдалбливать", я думаю, ты знаешь лучше меня...
И опять ни слова дополнительного пояснения сверх статьи. Ну все ж понятно, особо непонятливых уже послали на google/yandex. Вы не беспокойтесь, уважаемый, дорогу к поисковикам как-то и сами...
А вам остается только, как маститым гуру, поругивать бестолковых глупых новичков.
-
Поэтому хочется что бы начинающие пользователи все-таки поняли идею, и применяли её в дальнейшем, и меньше наступали на грабли. А то что это им прийдется "вдалбливать", я думаю, ты знаешь лучше меня...
И опять ни слова дополнительного пояснения сверх статьи. Ну все ж понятно, особо непонятливых уже послали на google/yandex. Вы не беспокойтесь, уважаемый, дорогу к поисковикам как-то и сами...
А вам остается только, как маститым гуру, поругивать бестолковых глупых новичков.
-
Dmitry Zlygin
цитата из статьи :
На схеме представлено дерево, описанное по всем правилам метода "Вложенных множеств". Квадратами обозначены узлы дерева, синие цифры в верхнем правом и верхнем левом углах узла - уровень и уникальный идентификатор соответственно, а красные цифры в нижних углах - это левый и правый ключ. Именно в этих двух цифрах - левом и правом ключе заложена вся информация о дереве. И если информацию о ключах занести в базу данных, то работа с деревом намного упрощается.
Обратите внимание на то, в каком порядке проставлены эти ключи. Если мысленно пройтись по порядку от 1 до 32, то вы обойдете все узлы дерева слева направо. Фактически это путь обхода всех узлов дерева слева направо.
последний абзац + картинка объясняют всю суть метода. Посмотри на картинку, пройдись мысленно по цифрам, подумай, еще раз подумай.
Можешь еще почитать начало статьи на http://detail.phpclub.ru/article/db_tree . Если и оттуда ничего не поймешь, то я объяснить ничего тебе не смогу.
-
2 Макс - спасибо за попытку объяснить, но лучше написано в документе, на который я привожу ссылку ("Древовидные структуры в SQL", по материалам статьи Joe Celko "Trees in SQL").
Понимаете, Макс, когда Phoinix пытается рассказать о nested sets, он не достигает понятности (плохой учитель :) ). Хотя в статье, на которую вы ссылаетесь, все же понятнее, чем у него. Ниже - объяснение еще проще, становится сразу понятным название метода хранения деревьев - "вложенные множества".
Чтобы изобразить древовидную структуру в виде вложенных множеств, заменим вершины графа овалами, где подчиненные овалы вложены один в другой. Основание дерева будет представлено самым большим овалом, который содержит все остальные овалы. Концевые вершины будут представлены самыми внутренними овалами, не содержащими внутри никаких других овалов, а вложенность будет показана иерархическими взаимоотношениями. Поля rgt и lft (я не использую зарезервированные слова RIGHT и LEFT) - это именно то, что показывает вложенность.
Если эта образная модель не работает, то представьте себе маленького червя, ползущего вдоль дерева против часовой стрелки. Каждый раз, когда он достигает правую или левую сторону вершины, он нумерует ее. Червь останавливается после того, когда он обойдет вокруг всего дерева и вернется назад к основанию.
... немного далее ...
Для преобразования графа в модель вложенных множеств вспомните о маленьком червячке, ползущем вдоль дерева. Червь начинает двигаться сверху - от основания - и обползает вокруг всего дерева. Когда он приходит к вершине, он присваивает значение стороне, которую он посещает и увеличивает значение счетчика на единицу. Каждая вершина получает два значения - одно для правой стороны и одно для левой.
-
всем не угодишь. Мне например пример с овалами совсем не нравится (хотя он объясняет суть названия метода).
А про червяка согласен, сам по нему разбирался.
-
Dmitry Zlygin
Понимаете, Макс, когда Phoinix пытается рассказать о nested sets, он не достигает понятности (плохой учитель ). Хотя в статье, на которую вы ссылаетесь, все же понятнее, чем у него. Ниже - объяснение еще проще, становится сразу понятным название метода хранения деревьев - "вложенные множества".
Возможно Вы и правы, но основное направление статьи - не что такое Nested Sets, а как ими управлять...
Можно конечно глупо скопировать статью, ссылку на которую дал Макс (собственно первые абзацы так и сделаны), потом дописать свое... Тогда вопрос: А почему в статье не описан сам принцив SQL запросов и что это такое, и вообще что за базы данных...
Вы не беспокойтесь, уважаемый, дорогу к поисковикам как-то и сами
Вот, Вот... Если что-то не понятно, то вперед в поисковики, если не помогло, тогда уже к автору за пояснениями...
P.S. Вообще непонятено рассуждение Dmitry Zlygin.
Если человеку, что-то не понятно, он может это спросить, у меня, лично, нет желания от кого-то что-то прятать, скрывать и доказывать, что он дурак, а я умный, раз ничего не понял из того что я написал.
Только как человек спрашивает, такой ответ он и получает.
Я знаю как работать с деревьями Nested Sets, Вы нет.
Я написал статью, которая по моему мнению, достаточно понятно раскрывает тему. Вы что-то не поняли из этой статьи. Я оскорбил Ваше самолюбие? Извините, не хотел...
У Вас возникли вопросы по ходу статьи, задавайте их, коментарии для того и существуют, для того, что бы делать уточнения, но никак не ставить оценку статье...
-
Привет всем!
Статья очень хорошая, написана очень хорошо, но к сожалению в ней неописано решение одной пролемы которая возникает у меня (да наверное не только у меня) при использовании этого алгоритма
Проблема в следующем
Как с помощью одного запроса получить всех список разделов дерева с указанными ID родителя для каждого узла. То есть
ID | ID parent | left_key | right_key | level
где ID parent - ID родительского узла.
Поясню для чего это мне надо
Вместе с сами алгоритмом для визульного представления я использую JS класс dTree который позволяе создавать меню типа проводника Windows.
Вот здесь то и требуеться для каждого пункта меню указывать ID его родителя.
Пока что делаю так
1)Запрашиваю список всех разделов
2)Для каждого раздела отдельным запросом определяю ID родителя.
Пока что всё нормально, но если в дереве будет штук 500 разделов то это 500 запросов в одном сценарии.Ужас!
Может кто то решил эту проблему?
Подскажите решение.
Спасибо!
-
Гость
Что-то не вижу никакой проблемы в решении данного вопроса...
Есть запрос для получения родителя узла:
SELECT id
FROM my_table
WHERE t2.left_key < t1.left_key AND t2.right_key > t1.right_key AND t2.level = t1.level - 1
Есть запрос выборки всех узлов:
SELECT id
FROM my_table
ORDER BY left_key
Объединяем 2 запроса:
SELECT t1.id AS id, t2.id AS parent
FROM my_table AS t1
LEFT JOIN my_table AS t2
ON t2.left_key < t1.left_key AND t2.right_key > t1.right_key AND t2.level = t1.level - 1
ORDER BY t1.left_key
Соответственно если родителя нет - parent = NULL
-
Phoinix
Спасибо!
-
2 Phoinix
Поэтому я сделал свое решение, которое позволяет 1 запросом перемещать узел в любую точку дерева...
Нельзя ли поподробнее? Если можно с примером...
Спасибо.
-
а если мы удаляем и добавляем узел не в конец ветки, а где-нибудь посередине.
тогда при удалении нужно добавить для подчиненных узлов:
UPDATE my_tree SET right_key = right_key – 1, left_key = left_key – 1WHERE right_key < $right_key AND left_key > $left_key
при добавлении для подчиненных узлов:
UPDATE my_tree SET right_key = right_key + 1, left_key = left_key + 1WHERE right_key < $right_key AND left_key > $left_key
Если это верно, то операцию перемещения можно будет свести к операции удаления и последующего добавления в новое место с предварительной выборкой данных узла.
-
Piter-G
тогда при удалении нужно добавить для подчиненных узлов:
Обычно удаляется вся ветка, поэтому, обновление для подчиненных узлов - не нужно...
при добавлении для подчиненных узлов:
Это как? ты добавляешь узел сразу с подчиненными узлами?
Если это верно, то операцию перемещения можно будет свести к операции удаления и последующего добавления в новое место с предварительной выборкой данных узла.
Не верно... все делается гораздо проще...
-
To Phoinix
Это как? ты добавляешь узел сразу с подчиненными узлами?
Нет, я вставляю узел за каким-то определенным узлом. У этого узла могут быть и подчиненные узлы. Тогда их нужно переподчинить вновь вставляемому узлу.
-
Piter-G
Вообще-то не только их, я все дерево следующее за местом вставки элемента
-
Phoinix
Ну, конечно, ты прав, это же очевидно. Я эти узлы и имел ввиду под подчиненными. Да и по поводу перемещения ты, наверное, прав. Так, как это описано в статье, действительно, может и не проще для понимания, но правильней.
-
Гость:
Пока что делаю так
1)Запрашиваю список всех разделов
2)Для каждого раздела отдельным запросом определяю ID родителя.
Выложи вкратце оба своих запроса, а мы их сошьём :)
-
Simon:
Выложи вкратце оба своих запроса, а мы их сошьём
Пардону прошу, второй странички форума не заметил ;)
-
Статья на редкость интересная. Не в том смысле, что интересные фрагменты встречаются редко.
Порадовали конкретные SQL-запросы для выполнения конкретных задач.
Скажите, а кто-либо использует эту схему для своих сайтов?
Интересует, как nested sets можно сравнить со схемой, которая применяется для GForge (http://gforge.org/):
id_topic
Номер узла, auto_increment, наш primary key.
sort_order
Порядок сортировки, +/- 10.
id_parent
Вышестоящий узел.
id_parent_root
Вышестоящий узел второго уровня вложенности. Если для данного узла такого уровня нет - тогда 0.
cnt_subtopic
Количество узлов внутри данного узла. Для вывода на экран "тема такая-то (10)"
ids_fullpath
Полный путь узла, разделенный каким-нибудь простым способом. Например запись " 10 :: 23 :: 45 " означает "45-й узел внутри 23-го, 23-й внутри 10-го, 10-й - самый главный и он же в id_parent_root)
Выбор фрагмента ветки любого уровня производится с помощью запроса:
SELECT ids_fullpath FROM table
WHERE ids_fullpath LIKE "% 23 %"
Пример полученного списка:
10 :: 23
10 :: 23 :: 45
10 :: 23 :: 45 :: 50
Выбор всей ветки:
SELECT ids_fullpath FROM table
WHERE id_parent_root = "10"
Обновление и добавление несложное - одна php-функция просто добавляет строку
без ids_fullpath, другая - рекурсивная, пересчитывает ids_fullpath
для только что вставленного id_topic и, если потребуется, для всей ветки, начиная c последнего узла (45),
заканчивая первым, root (10).
Содержимое таблицы:
id_topic id_parent id_parent_root cnt_subtopic ids_fullpath
10 0 0 3 10
23 10 10 2 10 :: 23
45 23 10 1 10 :: 23 :: 45
50 45 10 0 10 :: 23 :: 45 :: 50
Примерно такая схема применяется сегодня на sourceforge.net, freshmeat.net.
Только там базы PostgreSQL, поэтому значение для поля cnt_subtopic
вычисляется автоматически при обновлении дерева с помощью хранимой процедуры.
-
CLiI{er
Скажите, а кто-либо использует эту схему для своих сайтов?
Странный вопрос, тем более что я внизу написал даже на каких... ;)
А по сравнению:
Обновление и добавление несложное - одна php-функция просто добавляет строку
без ids_fullpath, другая - рекурсивная, пересчитывает ids_fullpath
для только что вставленного id_topic и, если потребуется, для всей ветки, начиная c последнего узла (45),
заканчивая первым, root (10).
При использовании Nested Set - достаточно одного запроса при обновлении (перемещении), и трех, при добавлении:
UPDATE дерева
INSERT узла
Впрочем это все написано и так в статье...
То же самое с выбором фрагмента ветки, хотя, у тебя это тоже один запрос, но использовать LIKE - несколько медленно
А если хочется выбрать и родительскую ветку и подчиненные узлы сразу?
-
Phoinix:
я внизу написал даже на каких...
Это сайты автора статьи. Разница между рекламными ссылками и применением предложенной схемы другими разработчиками в производстве сайтов всё же существует. О применении я и хотел услышать. И, если возможно, узнать, какие коммерческие продукты используют nested sets (я просто не в курсе).
-
Может я че-то не понимаю .. но что-то мне кажеться что этf система постороение дерева не быстрее обычной .. где ID и Parent_ID ...
-
Гость
что эта система постороение дерева не быстрее обычной
Может я тоже что-то не понимаю, но при чем тут построение дерева и скорость?
-
А если хочется выбрать и родительскую ветку и подчиненные узлы сразу?
select * from table where left_key >= $left_key and right_key <= $right_key order by left_key
Вроде так...
$left_key? $right_key - параметры родительского узла
P.S. А как перемещать ветку одним запросом? Можно пример запроса.
-
Есть две таблицы ... TreeView
Из одно обновить другую ...
Кто поможет сделать это красиво и быстро
Заранее благодарен за советы...
-
Ответ гостю:
SELECT tblTree.ID, tblTree.LeftKey, tblTree.RightKey, tblTree.Level, tblParent.ID FROM tblTree, tblTree AS tblParent WHERE tblParent.Level=tblTree.Level-1 AND tblParent.LeftKeytblTree.RightKey
UNION
SELECT ID, LeftKey, RightKey, 1, 0 FROM tblTree WHERE Level=1
ORDER BY LeftKey
-
Статья хорошая, отдельное спасибо за примеры. Но одного все же не хватает... Может Phoinix поделится примером как переместить ветку в любую часть дерева?
-
Daiz13
В статье 2 запроса UPDATE для перемещения узла и его подчиненных узлов...
Что именно-то показать?
-
Ну, например, как узел 16 сделать подчиненным узла 2. Интересует перемещение не вверх/вниз а в любую точку дерева.
Еще один глупый вопрос - я так понимаю, что корень у дерева только один?
-
Все классно и здорово, но либо я чего-то не понимаю, либо здесь никто кроме автора не вникал в статью. Уважаемый Phoenix, Вы очень помогли мне с организацией дерева каталогов, и все очень здорово работало, до момента перемещения узлов, все дело в том, что в этой статье Вы не указали необходимость обновления id узлов в момент перемещения, в данном случае операция корректно проводится с узлом лишь один раз после чего нумерация узлов становится хаотичной. Поправте меня если я не прав, буду очень признателен Вам за это.
С уважением, Алексей
-
colmcc
Вы не указали необходимость обновления id узлов в момент перемещения
id - обновлять нельзя!!! Причем не только здесь...
-
Спасибо, но тогда обьясните мне несведущему:
1
...3
...4
...5
2
.....
Перемещаем 5 на верх, получаем:
1
...3
...5
...4
2
.....
Проблема в том что при следующем перемещении "5" узла наверх, происходит ошибка определения left_key_near и right_key_near?
HELP ME!
-
colmcc
Значит неправильно определяешь right_key_near,
Он будет равен left_key родитльского узла...
-
Phoinix
Поэтому я сделал свое решение, которое позволяет 1 запросом перемещать узел в любую точку дерева...
Поделитесь тайным знанием плиз. заранее спасибо!
-
APL
Поделитесь тайным знанием плиз. заранее спасибо!
Ты статью-то хоть чтал??? ;)
-
Да, читал, но одним запросом у меня не получилось...
-
Phoinix
Огромное спасибо! Во всем разобрался, все прекрасно работает!
-
Содержание статьи соответствует названию, так же как и приведённые в ней схемы, т.к. они объясняют не то ЧТО ТАКОЕ деревья, представленные в виде вложеных множеств, а КАК ОНИ ИЗМЕНЯЮТСЯ при манипулировании.
Преимущества использования модели вложенных множеств в приложениях для веб очевидны. Разгружаются ресрурсы при выводе информации, т.е. там где и нужно. Упрощаются алгоритмы вывода, а соответственно сокращается время на разработку. Публиковать веб-сервисы одно удовольствие, просто бери и оборачивай в XML, причём из любого узла дерева.
По крайней мере мы в текущих проектах http://www.vhosting.ee/rus/contractors_active_competitions.cfm планируем их в той или иной мере использовать. А вот в какой, зависит от того, насколько нам удастся решить некоторые проблемы.
Проблема 1. Сортировка.
Пример.
Названия узлов на трёх языках. Требуется упорядочить вывод в алфавитном порядке.
Насколько я понимаю, порядок формируется на стадии создания дерева. Изменять его «на лету», это всё равно, что строить новое дерево для каждого запроса.
Пока остановились на таком решении.
Для каждого языка строится своё дерево и оно используется для вывода. Одно из них является основным, с ним проводятся все манипуляции при изменениях. Другие подчинённые и просто перестраиваются после внесение изменений в первое.
Вопрос.
Кто какие решения может предложить в плане Сортировки.
Кстати, можно использовать одновременно представления дерева как списка смежных вершин и как вложенных множеств, например новые разделы приложения создаются с использованием алгоритмов вложенных множеств, без изменения старых разделов, использующих модель списка смежных вершин. Для этого в таблице оставляется поле parent_id и его значение после изменений переопределяется на основании значений lft_key, rgt_key.
-
To all
По просьбам читателей, продолжение темы:
http://www.webscript.ru/stories/05/01/24/6319028
Правда практическое применение в Perl, но я заметил классы PHP не сильно отличаются... ;)
-
господа, а кто-нибудь решил проблему сортировки по названию категории при выводе полного дерева.
есть вариант, сортировать уже после выборки, но это жутко неудобно.
есть вариант, сразу находить правильное место вставки, но как реализовать - проблема...
-
Sherman
Если только вывод дерева производить через рекурсию...
Хотя, честно говоря, мне еще не попадалось выводить полностью все дерево с особой соритровкой, подчиненные узлы - да...
-
Phoinix, спасибо за великолепный модуль. Конечно пришлось дорабатывать его под свои нужды напильником. Но это скорее проблема не в модуле, а в том, что у меня руки кривые:) Вообщем респект.
ЗЫ. Уже выложил на спан?
ЗЫЗЫ. Сугубо моё ИМХО, но стоило бы хранить парент_ид. Впрочем, кому надо, тот добавит. У меня это заняло один вечер (чтение модуля, разбор запросов и добавление parent_id).
-
glebushka
Уже выложил на спан?
Еще нет, никак раздел POD не соберу... :(
Насчет parent_id - можно, конечно добавить надо подумать...
Там еще много разных мелочей, надо будет обновить. Например, при той же выборке родительской ветки или подчиненных узлов - текущий узел не выбирается, а он часто нужен...
-
У меня такая проблема.. Нужно одним запросом взять все категории первого уровня и максимум 3 второго, при учете, что я не знаю сколько всего первого
-
webxtor
[off]и фига себе изврат[/off]
А надо ли?
Только 2 запросами...
-
Надо еще бы!!
-
А как 2мя?
А еще вот. Нужно посчитать сколько всего компаний в родительских категориях и их детях,при этом выводя только первый уровень.
Придумал вот:
SELECT count( comps.id ) , cats1.name
FROM companies AS comps, categories AS cats, categories
as cats1
where cats.id = comps.category_id
and cats.right_key <= cats1.right_key
and cats.left_key >= cats1.left_key
and cats1.level = 1
GROUP BY cats1.name
Работает, но думает треть секунды.. может можно как-то обойтись 2мя таблицами?
-
Phoinix:
ни фига себе изврат
К стати, почему изврат? Я ничего не делаю в своей работы ради исследований или интереса. Во всем, что я делаю, есть практическая необходимость.
Очень часто на сайтах необходимо отобразить все главные категории и несколько дочерних (потом обычно идет троеточие).
Вот я и хочу сделать все как можно меньшим количеством запросов.
Привожу пример:
http://www.alibaba.com/companies/0/company.html
-
Помогите решить задачку. Вот исходные данные
1.
(http://snowrush.ru/files/nested/ex1.gif)
2.
(http://snowrush.ru/files/nested/ex2.gif)
По условию известны узлы, выделенные оранжевым. Нужно выбрать все узлы, выделенные зеленым.
-
Твои предложения?
-
Решение было найдено благодаря ru_mysql коммунити в livejournal
SELECT DISTINCT
j2.*
FROM tree AS t1
LEFT JOIN tree AS tr ON tr.id = $root_node_id
LEFT JOIN tree AS j1 ON (j1.l <= t1.l AND j1.r >= t1.r)
LEFT JOIN tree AS j2 ON (j2.l >= j1.l AND j2.r <= j1.r AND j2.level IN (j1.level, j1.level + 1))
WHERE t1.id = $current_node_id AND j1.l >= tr.l AND j1.r <= tr.r AND j2.level >= tr.level
ORDER BY j2.l ASC
$root_node_id - Id корня
$current_node_id - Id выделенного узла
id - идентификатор узла
l - left key
r - right key
level - уровень
Запрос выбирает все "приоткрытое" дерево, начиная от указанного корня. Полезен для строительства "приоткрытого" меню любого уровня вложенности.