Модераторы: skyboy

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Выдрать из 1 таблицы несколько значений каскадом 
:(
    Опции темы
Aver78
Дата 1.4.2008, 10:06 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бывалый
*


Профиль
Группа: Участник
Сообщений: 185
Регистрация: 21.4.2007

Репутация: нет
Всего: нет



Есть таблица. 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 ?
PM MAIL   Вверх
Feldmarschall
Дата 1.4.2008, 10:30 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок
****


Профиль
Группа: Участник
Сообщений: 2641
Регистрация: 11.12.2007

Репутация: 3
Всего: 32



нет
PM   Вверх
skyboy
Дата 1.4.2008, 10:49 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


неОпытный
****


Профиль
Группа: Модератор
Сообщений: 9820
Регистрация: 18.5.2006
Где: Днепропетровск

Репутация: 41
Всего: 260



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

Добавлено через 37 секунд
в общем виде, как уже сказал Feldmarschall, ответ - нет. потому как поддержка ХП есть только начиная с 5 версии.
PM MAIL   Вверх
Aver78
Дата 2.4.2008, 00:03 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бывалый
*


Профиль
Группа: Участник
Сообщений: 185
Регистрация: 21.4.2007

Репутация: нет
Всего: нет



Так мне под 5-ую и надо. Напиши плиз как, или хотя бы линк на нужное место документации.
PM MAIL   Вверх
Feldmarschall
Дата 2.4.2008, 00:29 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок
****


Профиль
Группа: Участник
Сообщений: 2641
Регистрация: 11.12.2007

Репутация: 3
Всего: 32



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

Вообще, простые задачи надо решать простыми средствами.
PM   Вверх
Aver78
Дата 2.4.2008, 01:26 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бывалый
*


Профиль
Группа: Участник
Сообщений: 185
Регистрация: 21.4.2007

Репутация: нет
Всего: нет



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

Это сообщение отредактировал(а) Aver78 - 2.4.2008, 01:28
PM MAIL   Вверх
Feldmarschall
Дата 2.4.2008, 01:37 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок
****


Профиль
Группа: Участник
Сообщений: 2641
Регистрация: 11.12.2007

Репутация: 3
Всего: 32



Цитата(Aver78 @  2.4.2008,  01:26 Найти цитируемый пост)
цель-то, как раз - минимизировать кол-во запросов.

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

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

Цитата(Aver78 @  2.4.2008,  01:26 Найти цитируемый пост)
 она может вырасти и до нескольких тысяц

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

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

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


PM   Вверх
Aver78
Дата 2.4.2008, 03:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бывалый
*


Профиль
Группа: Участник
Сообщений: 185
Регистрация: 21.4.2007

Репутация: нет
Всего: нет



Цитата

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

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

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

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

А здесь что три, что один - разницы не будет никакой.

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

И отличать реальные проблемы от мнимых. Ты сейчас себе выдумал проблему. И для её решения создаешь себе реальную.

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

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

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


Это сообщение отредактировал(а) Aver78 - 2.4.2008, 04:34
PM MAIL   Вверх
Feldmarschall
Дата 2.4.2008, 08:47 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок
****


Профиль
Группа: Участник
Сообщений: 2641
Регистрация: 11.12.2007

Репутация: 3
Всего: 32



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

Цитата(Aver78 @  2.4.2008,  03:24 Найти цитируемый пост)
Маловероятен такой объем, но вероятен. И столкнуться с этой проблемой через год не хотелось бы.

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

Цитата(Aver78 @  2.4.2008,  03:24 Найти цитируемый пост)
Прежде чем ставить я пойму как это работает. ПРосто одно дело искать с нуля, другое понять рабочий код.

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

Цитата(Aver78 @  2.4.2008,  03:24 Найти цитируемый пост)
Только нужно еще учитывать время на пересылку запроса. Критично как раз оно.

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

Цитата(Aver78 @  2.4.2008,  03:24 Найти цитируемый пост)
Мне кажеться, что чем больше ты прдусмотришь при создании

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

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

Цитата(Aver78 @  2.4.2008,  03:24 Найти цитируемый пост)
А вот это уже не при чем. Если я не буду учитывать 'может',

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

Это сообщение отредактировал(а) Feldmarschall - 2.4.2008, 08:52
PM   Вверх
skyboy
Дата 2.4.2008, 15:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


неОпытный
****


Профиль
Группа: Модератор
Сообщений: 9820
Регистрация: 18.5.2006
Где: Днепропетровск

Репутация: 41
Всего: 260



Цитата(Aver78 @  1.4.2008,  23:03 Найти цитируемый пост)
Напиши плиз как, или хотя бы линк на нужное место документации. 

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

Добавлено через 1 минуту и 52 секунды
кроме того, выбрать все одним запросом, а в дерево собрать уже данные на стороне клиента(в смысле - РНР, Ruby, Python, ASP - что ты там используешь как клиент БД) будет делом трех строк кода.
это если обычная структура("ид" + "ид родителя").
если nested sets - вполне себе выбирается одним запросом. но, раз уже ссылку давал, видимо не подошло чем-то
PM MAIL   Вверх
Aver78
Дата 3.4.2008, 01:15 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бывалый
*


Профиль
Группа: Участник
Сообщений: 185
Регистрация: 21.4.2007

Репутация: нет
Всего: нет



Цитата

Как же я люблю эти "через год"

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

Рабочий принцип чего ты хочешь понять? Программирования хранимых процедур под мускуль?

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

Обоже. Ну где вы себе эти страшилки находите? Кто вам их рассказывает, руки бы ему оторвать?

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

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

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

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

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

Какя ? Я вроде все ссылки перебрал. И что такое XP ? Я спрашивал просто про запрос. 
PM MAIL   Вверх
skyboy
Дата 3.4.2008, 09:47 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


неОпытный
****


Профиль
Группа: Модератор
Сообщений: 9820
Регистрация: 18.5.2006
Где: Днепропетровск

Репутация: 41
Всего: 260



Цитата

И что такое XP ?

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

Я вроде все ссылки перебрал.

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

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

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

Напиши рекурсивный код. и займись оптимизацией того, что действительно требует этой оптимизации
PM MAIL   Вверх
Feldmarschall
Дата 3.4.2008, 10:08 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок
****


Профиль
Группа: Участник
Сообщений: 2641
Регистрация: 11.12.2007

Репутация: 3
Всего: 32



Цитата(Aver78 @  3.4.2008,  01:15 Найти цитируемый пост)
Вообще то я изначально спрашивал про возможную структуру запроса, это ты себе навыдумывал что мне нужная новая процедура в нем.

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

Цитата(Aver78 @  3.4.2008,  01:15 Найти цитируемый пост)
Мне их никто не расказывает, я их вижу регулярно. Конечно если у сайта 1 посетитель - он жк админ, то можно не париться.

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

Я жду.

PM   Вверх
Aver78
Дата 3.4.2008, 16:12 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Бывалый
*


Профиль
Группа: Участник
Сообщений: 185
Регистрация: 21.4.2007

Репутация: нет
Всего: нет



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

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

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

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

В общем тема закрыта. Всем спасибо.
PM MAIL   Вверх
Feldmarschall
Дата 3.4.2008, 16:43 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок
****


Профиль
Группа: Участник
Сообщений: 2641
Регистрация: 11.12.2007

Репутация: 3
Всего: 32



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

Цитата(Aver78 @  3.4.2008,  16:12 Найти цитируемый пост)
если начинать решать все такие вопросы в лоб, 


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

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

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

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

Это сообщение отредактировал(а) Feldmarschall - 3.4.2008, 18:28
PM   Вверх
Ответ в темуСоздание новой темы Создание опроса
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | MySQL | Следующая тема »


 




[ Время генерации скрипта: 0.0948 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.