Есть таблица. id, id_parent, name. Соответственно id_parent равен id записи которой принадлежит.  Пример

id  id_parent name
1         0         Имя 1
2         0         Имя 2
3         1         Имя 3
4         3         Имя 4
5         4         Имя 5

Можно ли 1 запросом выдернуть, по 1 ID, всю ветку ?.  Напрмер я входящее id=5. Я получаю записи с id=4, 3, 1 ?

нет

да, если использовать (рекурсивную)хранимую процедуру(точнее - функцию). но это будет намного медленнее, чем если использовать как раз "заточенный" для подобных выборок механизм nested sets(хорошая статья также есть на dev.mysql.com)

Добавлено через 37 секунд
в общем виде, как уже сказал Feldmarschall, ответ - нет. потому как поддержка ХП есть только начиная с 5 версии.

Так мне под 5-ую и надо. Напиши плиз как, или хотя бы линк на нужное место документации.

Сегодня в соседнем форуме давали ссылку. http://dev.mysql.com/tech-resources/articl...hical-data.html
Однако я должен заметить, что
Во-первых, никакой практической нужды делать все одним вызовом mysql_query нет. Вполне можно подняться по ветке рекурсивно.
Во-вторых, совсем не обязательно хранить данные именно так - можно использовать и другие структуры.
В-третьих, в 90% случаев использзования деревьев в вебе, эти деревья представляют из себя чахлые кустики в несколько десятков веток. И проще всего с ними работать, просто загрузив все дерево одним запросом в память.

Вообще, простые задачи надо решать простыми средствами.

Я что то не додумался до альтернативного способа, да и смысл ? Так вся структура в одной ветке. По поводу рекурсии, то да, разумеется я могу выполнить несколько рекурсивных запросов. Но в цель то как раз минимизировать кол-во запросов. В идеале - как раз 1. А рботать со всей веткой - причина примерно та же. Во первых в несколько раз вырастает количество данных, даже если ветка небольшая, а ведь она может вырасти и до нескольких тысяц.. А во вторых лишние затраты на обработку результата. 
К сожалению с инглишом я на Вы, поэтому от линка мне тоже мало проку ((

Это сообщение отредактировал(а) Aver78 - 2.4.2008, 01:28

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

Начинающим программистам следует научиться понимать, что дело не в количесте запросов, а в их качестве.
И отличать реальные проблемы от мнимых. Ты сейчас себе выдумал проблему. И для её решения создаешь себе реальную.
Напишут тебе сейчас эту ХП. Неужели тебе так хочется иметь в своем проекте элемент, в котором ты не понимаешь ни буквы. А если перестанет работать? Опять пойдешь на форум - "исправьте"?


Не надо путать ветки и листья.
элементов в каталоге могут быть тысячи, да. но разделов - десятки.

Но вообще нравится мне это сослагательное наклонение в программировании. "она может". ага. 
Я тоже люблю это "может".
Версия БД может поменяться.

И сама БД может поменяться. Как заходит разговор об универсальных библиотеках доступа к БД - так тут же нахордится стая ораторов, которые начинают петь песни про то, что можно сменить бд одной строчкой в коде. Но при этом элементарные задачи решаются не предназначенными для этого средствами - ХП, юнионами, подзапросами. А потом все это будет переезжать на другую БД, ага. одной строчкой.

Я не путаю. Я говорю именно о категориях. Маловероятен такой объем, но вероятен. И столкнуться с этой проблемой через год не хотелось бы.

Ни в коем разе. Прежде чем ставить я пойму как это работает. ПРосто одно дело искать с нуля, другое понять рабочий код.

Только нужно еще учитывать время на пересылку запроса. Критично как раз оно. Особенно если БД на другом сервере.

Мне кажеться, что чем больше ты прдусмотришь при создании, тем меньше будет геммороя в сопровождении и апгрейде. И какую я себе реальную проблему создал, я не понимаю. Что бы написать рекурсивный код для таких запросов нужно минут 10. Я просто отложил этот кусок, а вдруг есть более грамотное решение. 

А вот это уже не при чем. Если я не буду учитывать 'может', достаточно создать 1 категорию, вдруг остальные не понадобятся.


Это сообщение отредактировал(а) Aver78 - 2.4.2008, 04:34

Какая прелесть  


Как же я люблю эти "через год".   
Что ж, "плох тот солдат, который не мечтает о маршальском жезле", говорил А.В.Суворов. Ага. Мечтаем. Ну хорошо. Ладно. Реальное удобство меняем на мечту прекрасную, ещё неясную.


Какие похвальные стремления.
Рабочий принцип чего ты хочешь понять? Программирования хранимых процедур под мускуль? То есть, абсолютно нового и неизвестного тебе языка? И ты думаешь, что кого-то убедишь, будто можешь изучить, к примеру, ПХП или Си++ по одному кусочку кода? 
При том, что программирование ХП само по себе - извращение, сравнимое с поклейкой обоев в квартире через замочную скважину: ни тебе отладки нормальной, ни визуальной среды, ты гордо заявляешь, что по одному примеру изучишь весь язык.
Может, умерить фантазию, все-таки?   


Обоже. Ну где вы себе эти страшилки находите? Кто вам их рассказывает, руки бы ему оторвать?
Если у тебя такое страшное действие, как ПЕРЕСЫЛКА ЗАПРОСА занимает какое-то ощутимое время, то твой грандиозный каталог ляжет, не начав работать.
Не надо выдумывать себе проблемы. Вопрос, который я задаю любителям "сделать все одним запросом": А че ни один не спросил до сих пор, как получить ВСЮ информацию для сайта одним запросом? ХП это сделают, на раз! Это ж какая экономия!
При этом миллионы сайтов работают, выполняя по 10-30 запросов на страницу, и ничего - не загнулись почему-то. А тут пишется новое гениальное творение, которое обязательно умрет от двух лишних запросов, ога   


Ага. Опять очень красивые и мудрые размышления.
Покупая себе автомобиль, следует подумать - а вдруг придется на дачу возить песок и удобрения... поэтому надо предусмотреть все, и купить самосвал! С пожарной цистерной. 

Предусматривать надо. Но опять же - исходя из реалий, а не фантазий.
Если у тебя будет каталог на тыщу элементов, то выбранный тобой способ хранения дерева, скорее всего, вообще не подойдет. И нужно тогда все менять - структуру БД и средства работы с ней. Покупать самосвал.
Не хочется на самосвале на работу и в магазин кататься? Не хочется все переделывать? Умерь фантазию.


Отлично. Вот и учитывай. Что сменится версия БД, которая ХП не поддерживает!   

Это сообщение отредактировал(а) Feldmarschall - 2.4.2008, 08:52

по ссылке ходил? смотрел статью? там же по-русски!
если тебе сильно хочется в виде ХП, то учти, что рекурсивная ХП может работать нестабильно.

Добавлено через 1 минуту и 52 секунды
кроме того, выбрать все одним запросом, а в дерево собрать уже данные на стороне клиента(в смысле - РНР, Ruby, Python, ASP - что ты там используешь как клиент БД) будет делом трех строк кода.
это если обычная структура("ид" + "ид родителя").
если nested sets - вполне себе выбирается одним запросом. но, раз уже ссылку давал, видимо не подошло чем-то

Ага, если тебя прет выслушывать претензии через год с 2 десятков сайтов и все это править в стиле - на том свете отосплюсь, то удачи.

Вообще то я изначально спрашивал про возможную структуру запроса, это ты себе навыдумывал что мне нужная новая процедура в нем.

Мне их никто не расказывает, я их вижу регулярно. Конечно если у сайта 1 посетитель - он жк админ, то можно не париться.

Больше похоже на кухонный комбайн, что бы можно было без проблем менять насадки.

Добавлено через 4 минуты и 18 секунд

Какя ? Я вроде все ссылки перебрал. И что такое XP ? Я спрашивал просто про запрос. 

Не знаю. eXtrim Programming? ХП - это хранимая процедура(незавысимая единица кода в СУБД, которая может быть выполнена).

В той, что я приводил(первая ссылка, где статья на русском языке) достаточно и механизм описан, и приведены примеры запросов.

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

Напиши рекурсивный код. и займись оптимизацией того, что действительно требует этой оптимизации

Запросом - нельзя. Об этом я тебе сказал с самого начала.


Не надо рассказывать мне сказки. 
Покажи мне сайт, производительность которого страдает под какой угодно нагрузкой, при добавлении двух вызовов mysql_query, которые запрашивают из БД по одной строке по первичному индексу.
Или возьми свои слова обратно.

Я жду.

Из за двух - возможно и нет. Но если начинать решать все такие вопросы в лоб, то набежит не 2 , а 22. Вон возьми например php-nuke. Где то там я видел статистику - 38 запросов при каждом обращении к странице. А переписаная она же slaed 3-4. И посмотри их по быстродействию. Тоже решили, а, запрсом больше запросом меньше.

Добавлено через 1 минуту и 46 секунд

Понятно. Буду знать.

В общем тема закрыта. Всем спасибо.

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



Никто тебе не предлагает "все" "такие" вопросы решать в лоб.
Я отвечал не про все вопросы, а про один, конкретный.
Конкретная задача получения всех родителей легко решается циклом на пару итераций.

Если будут другие вопросы - для них будут другие решения. А единственного ответа на все вопросы не существует.
Поэтому не надо критиковать мое решение только потому, что оно не подходит на все случаи жизни.

Если у тебя есть конкретные вопросы - задай. 
Работа с деревьями  - вопрос весьма неоднозначный. Единственно правильного решения не существует. Часто даже выбрать между двумя способами хранения дерева бывает непросто.

Но есть типовые решения.
К примеру, всякие древовидные комментарии удобно делать с помощью Materialized Path
Небольшие иерархические структуры, типа меню сайта - твоим Adjacency List, причем выбирать сразу всю структуру одним запросом, и пользоваться ей во всех частях сайта - при выводе меню, при построении пути к странице, и так далее.
Если требуется большой каталог, причем с сортировкой, которая включает как иерархию каталога, так и наименования товаров - Nested Sets или тот же Materialized Path. Эти спообы позволяют строить дерево одним запросом. 

Это сообщение отредактировал(а) Feldmarschall - 3.4.2008, 18:28