Здравствуйте! Помогите пожалуйста мне разобраться с этим запросом. Я не понимаю как его составить.

У меня есть таблица my_table
Поля таблицы:

id, parent, value

идентификатор, ид. родителя, значение


Мне нужно получить например 50 записей, но чтобы они шли типа с вложеностью. И отсортированные по идентификатору в обратном порядке.
Например таблица заполнена:


мне нужно вывести 2 "вложености"
На выходе должно быть:


Ну типа 2 родителя со всеми его наследниками. 
Это вообще реализуется одним запросом? 
Не одним запросом я знаю как это реализовывается. Но в этом случае может получится очень много запросов. А это веб-приложение и очень много запросов не желательно.

Одна хранимая процедура... устроит?

Подойдет все! Пишите!  

Глубина дерева фиксирована? если нет, в MySql, одним зарпосом AFAIK - не реализуется.

Если фиксирована, столько левых джойнов, какова глубина дерева. 
В вашем случае два:


Это сообщение отредактировал(а) Zloxa - 2.5.2009, 00:16

Zloxa, нет, не фиксирована. 
А можно ввобще по минимуму запросов? Пару штук, ну до 10 хотябы.
Я раньше делала так: Получал одним запросом все корневые записи у которых поле parent = 0, а потом, чтобы получить вложенные записи, приходилось делать один запрос для каждого.
И было у меня порядка 100 запросов на странице.

  





   Что здесь происходит!? Очепятался наверное? 

По сути:

Если бы можно было добавить столбец с информацией об уровне иерархии (например level), то можно было бы попробовать делать так:

1. Ищем максимальное значение level в таблице (Отдельным запросом).
2. JOIN'ом во внешнем запросе вытаскиваем информацию из level-количества подзапросов, где каждый подзапрос - это поля одного уровня иерархии. (Или представления делаем или таблицы даже например).

Например:
Запрос


Для таблицы:


Вернет такие данные:


Основной недостаток, что хоть и выборка будет выполняться одним запросом его прийдется постоянно модифицировать в зависимости от текущей глубины вложенности. Хотя и сразу можно сделать запрос с "запасом" уровней эдак на 20, но вот сколько по времени такой запрос будет выполняться  ?

очепятка  

Спасибо! 
 ого запрос. долго вы его составляли? 
Буду пробовать.
Еще буду искать может есть другие варианты.

Оооо! Я кажется придумал. 
Добавить еще одно поле, куда записывать идентификатор корневой записи всех его наследников.
Потом первым запросом выбрать все корневые записи нужное количество штук. Вторым запросм выбрать все записи, которые имеют в новом поле идентификаторы, полученные первым запросом. 
Имеем два рез. множества, склеиваем их. Ну и сортируем в дерево. Вроде все должно получится.

Но вот как теперь при добавлении новой записи знать идентификатор корневой записи....

а разве иерархические запросы (Hierarchical Query) в данной ситуации не проканают?

ну типа (скопировал из доки):

SELECT employee_id, last_name, manager_id, LEVEL
   FROM employees
   CONNECT BY PRIOR employee_id = manager_id;

EMPLOYEE_ID LAST_NAME                 MANAGER_ID      LEVEL
----------- ------------------------- ---------- ----------
        101 Kochhar                          100          1
        108 Greenberg                        101          2
        109 Faviet                           108          3
        110 Chen                             108          3
        111 Sciarra                          108          3
        112 Urman                            108          3
        113 Popp                             108          3
...

Нет  , это он с виду такой страшный, а на самом деле ничего серъезного  , сложнее делать короткие корректные и быстрые запросы, а крокодила "забабахать" - раз плюнуть!



Незачто   ! Только рекомендую прислушаться к мнению тех, кто поопытнее меня  , например Zloxa - у него опыта больше  !



Тоже вариант.



Да очень просто, например так:



С учетом того что поле ID генерируется автоматически, для приведенной выше таблицы получим в результате:


Если ввести поле корневого родителя, то и его в запрос засунуть, что б и оно вводилось...

То Sokol71


Ваш пример из доки на MySQL?

Это сообщение отредактировал(а) Gluttton - 2.5.2009, 18:37

иерархических запросов нет в MySQL. а вот в PostgreSQL есть полезный тип ltree.

для данной задачи имхо с успехом можно применять такой способ:



длина строки - уровень вложенности, префикс - путь от родителя

Если тебе ВСЕГДА надо отбираться от корня, это очень даже вполне выход.
По хорошему бы (для того, чтобы самому же не ошибаться) накинуть еще и fk на пару (parent, root). Но, судя по тому что у тебя parent принимает значения = 0, ты такой мелочью как fk - брезгуешь 

А отбираться можно и одним запросом(с подзапросом).

fk - foreign key? Я не брезгую, я просто человек далекий, мало что понимаю в этом. Если оно тут нужно, то скажите куда добавить  
Хотя вы правы, бывает нужно построить дерево не от корневой записи.
Как вообще составляют таблицы (структура) для таких случаев (деревья)? Может я не правильно сделал таблицу?

Если БД находиться на этапе проектирования (а не эксплуатации), то поменяй СУБД и используй рекурсивные запросы.

возможно проще и быстрее вынести рекурсию в Php

Добавлено через 2 минуты и 57 секунд
Zloxa, 

не выйдет: это будут записи, добавленные первыми, а порядок добавления в иерархию, видимо, не определен.

Это было





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

Если отношение количества чтений дерева к количеству его модификаций стремится к нулю, ваш вариант вполне жизнеспособен, дерево стоится на клиенте и никому от того не плохо.


И данные геморои поменять на другие (с лицензированием, обслуживанием и др.) 

Нет. Я наивно предположил, что ключевое слово SQL ... оказалось, что ключевое слово MY ...