нужно вывести всех родителей дерева их id и name?  MySQL
ни где не нашел это

есть столбцы:  id | parent_id | name

сделал рекурсию в скрипте, вывесло, но делает больше 5-10 запросав, сказал что не правильно...

как лучше всего? сделать процедуру в MySQL или еще как-то можно?

может включить кэширвоание и сделать рекурсию обычную? кэширование спасет? оно не будет повтороно для каждого родителя делать запрос?



Это сообщение отредактировал(а) gcc - 3.5.2009, 10:16

вот нашел
http://cpansearch.perl.org/src/BJEPS/DBIx-Tree-1.9/Tree.pm

оно по-моиму без рекурсии, там можно указать start_id

оно сразу всю таблицу вытаскивает? если да, то это не подхожит...


UPD: нашел http://www.getinfo.ru/article610.html

Это сообщение отредактировал(а) gcc - 3.5.2009, 10:17

есть два простых решения: не химичить с тем, что не подходит 
либо сменить стрктуру хранения на nested sets, либо добавить в каждую запись поле, в котором серализированно хранить идентификаторы всех предков(например, так: "00001.00005.00015.00128").  в обоих случаях для выбора родителей рекурсия не будет нужна.

skyboy, при серилизации как мне вывести дерево, точнее всех под разделов с указаного раздела, одим или нескольким запросами?

==============

использую MySQL, MyISA

NestedSet не понравился, говорят он ресурсовемкий если таблица большая, не зря придумывали много для дерева в FriBide, Oracle, etc

и таблицу я создал только c parent_id
если добавить сейчас NestedSet , то переписывать прейдется

не плохой вариант: серилизировать всех родителей каждого дерева

очень замечательно, можно переносить разделы, добавлять в любой раздел, ресурсов оно не затребует, несколько UPDATE - можно вставить один запросом, если я правильно понимаю...

может есть смысл innoDB использовать с внешними ключами? только елси там есть реально решения... если оно там есть?
или какой вариант лучше?

Это сообщение отредактировал(а) gcc - 31.7.2009, 15:23

Вывожу потомков раздела с "00007"(типичное значение поля parents: "00003.00007.00010"):

но этот вариант напряжен при выборке: в отличие от одного поля parent_id и пары left_id+right_id в nested sets, сериализированный путь - не индексированное числовое поле. Потому разница в скорости выборки для сериализированного пути и других вариантов должно отличаться уже для небольшого количества элементов(в тысячах), правда, экспериментом подтвердить не могу.

я думал что нужно серилизировать только вершние разделы, например от 0007

0001
     0004
        0007

надо нижние тоже серилизировать, а как нижние серилизировать? создаю я подраздел в каком-то разделе, как мне узнать все нижние? ( если всего разделов 1000 и больше, то нужно 1000 UPDATE одним запросом сделать?) (верхние понятно - у родителя)

а есть ли документация? 

я не нашле http://www.google.com.ua/search?hl=uk&...%8C&spell=1





Это сообщение отредактировал(а) gcc - 31.7.2009, 15:44

Nested Sets очень плох на модификации данных. Многопользовательское редактирование можно забыть. Зато дает быстрый селект.
Хранение полного пути к ноде(ранее было, как я понял, названо сериализацией) - одинаково плохо как на выборке, так и на редактировании. Не снимает порбемы многоползовательской модификации.
Самый компромиссный вариант - рекурсия с клиента или хп.
однако не понятно кто "сказал что не правильно" и чем "он" руководствовался.

Это сообщение отредактировал(а) Zloxa - 31.7.2009, 15:50

ладно тогда nested sets

я вот нашел новые стать:
(не много по другому сделано)
http://habrahabr.ru/blogs/perl/65495/

вот есть на триггерах:
http://habrahabr.ru/blogs/mysql/63883/
http://habrahabr.ru/blogs/postgresql/63416/

не много старые
http://doc.prototypes.ru/database/nestedsets/perl/module/
http://webscript.ru/stories/04/09/01/8197045

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

я вот нашел что Firebird хратит ссылку родительский узел

Firebird будет лучше? она бесплтаная вродебы, есть на Linux и FreeBSD 

http://gsbelarus.com/gs/modules.php?name=N...cle&sid=314

ты показываешь такую же стурктуру, о которой говорил в своем первом посте.

в первом посте нету


и в первом посте кроме рекурсии практически никак нельзя вынуть вверхние или нижние...?

а тут для извлечения всех потомков узла Р и всех потомков потомков


а чтобы все вложенные уровни для узла с идентификатором, заданным параметром Р




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

ну, так тебе ничто не мешает и под mysql использовать foreign key для каскадного удаления всех потомков при удалении родителя.

перебор неограниченной глубины связей можно либо через итерации(через курсоры, видимо, чтоб средствами sql), либо через рекурсию. и твой приведенный запрос для выбора потомков и потомков потомков будет иметь одинаковую функциональность что в firebird, что в mysql. 
если в какой-то СУБД и есть специальный структуры для хранения/обработки графов/деревьев, то пока что про них не было сказано ни слова - список смежности(в виде поля parent_id), сериализацию пути("00001.00008.00010") и Nested Sets можно реализовать в любой СУБД. будь то Firebird или mysql.
и, да, в чем у тебя вопрос? на вопрос 

тебе Zloxa, привел аргументы касательно 3 способов. 
кроме того: ты ищешь "лучшую"(по каким параметрам?) реализацию хранения графа под определенную СУБД(MySQL, судя по первому посту) или ты выбираешь СУБД под хранение графа(то MySQL, то Firebird)?

да, я уже выбрал - это NestedSet либо рекурсия, просто хотел спросить, может есть что-то другое, если была СУБД в которой были бы опреаторы для работы с деревом я бы выбрал ее... и с начало надо подумать над архитектурой БД, правильно? например, не рекоммендуется в MySQL использовать рекурсию...

а как этот запрос написать в MySQL чтобы посмотреть всех родителей ввреху (не дерево выводить, а иммено родителей)?

 
не много не понял  parent = :P это тоже самое что и   parent = $p

еще что-то не смог придумать запрос, если у каждого раздела есть поле active (0 или 1 значение)  как изменить у всех подразделов поле active на 1 (тут скорее всего NestedSet...)


Это сообщение отредактировал(а) gcc - 1.8.2009, 13:34

Ты же сам упомянул об этих СУБД

про каких этих, о Firebird? то есть у нее дерево лучше будет?

там только статьи что-то не нашел на русском, кроме этой  http://gsbelarus.com/gs/modules.php?name=N...cle&sid=314

надо будет на англиской по искать



Это сообщение отредактировал(а) gcc - 1.8.2009, 19:55

надо искать. в oracle есть специальные операторы по работе с деревом, если я не ошибаюсь. что, купишь сервер oracle?
может, лучше разбраться с тем же nested sets?
все равно нет универсального "самого лучшего из всех возможных решений" и использование того же oracle проигрывает в переносимости использованию того же nested sets.

У Оракли есть бесплатная ограниченная версия.
Говорят PG тоже умеет деревья обходить.

Это сообщение отредактировал(а) Zloxa - 2.8.2009, 10:02

ok посомтрю на PG

ради интереса, такой запрос в принципе тоже првильный?
поставить порядок ступеней (по горизонтале) допустим 50 (хотя можно меньше)

тех элементов которых нету, она прогнорирует?
а в скрипте все что отсутсвует удалить


Это сообщение отредактировал(а) gcc - 6.8.2009, 03:35

интересует вопрос как работать с дереовм? если таблица неограниченная планируется

вынест ивсе будет навернео не правильно... 
а можно вывести его постранично? или как-то по нему перещатся? 

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

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

Это сообщение отредактировал(а) gcc - 7.8.2009, 20:57

сделал, написал не большую заметку

сейчас думаю над архитектурой еще одного дерева...

мне показалось что NestedSet не подойдет для него так как NestedSet все операции кроме SELECT ресурсоемкие!!

недостатки в Nested Set: если вы заметили, точно такая же рекурсия, только там идет UPDATE ресурсоемкий который все дерево изменяет (очень много записей) по этому я нашел решение где-то на opennet.ru на innodb с ускорением за счет внешних ключей и транзакции (чтобы дерево не развалилось во время изменение структуры). НО еще говорят что если innodb с большой базой, то грузит сильно сервер, неоднократно сталиквался, но в приципе мне все равно,  но тут не знаю, не тестировал... 

про мое дерево долго рассказывать:

1) 

щас нарисую

"Корень дерева" --> "разедел1"
````````````````` "разедел2"->>>"разедел1"
````````````````` "разедел3"````"разедел2"
````````````````` "разедел4"````"разедел3"->>>>>>"разедел1"
````````````````` "разедел5"````````````````````"разедел2"
````````````````` "разедел6"````````````````````"разедел3"
```````````````````````````````````````````````"разедел4"

из этого:
а) у кадого раздела может быть свой "подраздел(ы)"
б) у кадого раздела может быть "тема(ы) сообщения" как на этом форуме
 б2) у темы есть коментарии


думаю все понятно?

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

===
при обычном parent_id:

id
parent_id
(можно еще level)

Преимущества дерева
1) перенос 
2) Добавление
3) Нормальный SELECT и SELECT всех родителей  (SELECT сразe 50-100 ступеней можно сделать,( т.е. ограничить) а лишние удалить, либо рекурсию) все остальное нормально

Недостатки:
1) удаление всего дерева затруднительно (рекурсию надо делать, или процедуру)
  НО в условии, например присутствует, что пользователи не могут когда они захотят все удалить, литит удлаения должен быть (проблем не будет)
2) узменение атрибута узла и всего поддерева (например надо все дерево скрыть начиная с конкретного узла) (рекурсию надо делать, или триггер)

можно записывать level уровень, чтобы сделать еше быстрый SELECT всех родителей и  в один НОРМАЛЬНЫЙ запрос

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

вообщем, как? 
писал старался, хотел узнать может есть замечания какие-то?

Это сообщение отредактировал(а) gcc - 4.10.2009, 17:45

этих проблем в принципе не существует(изучите ниже приведенный пример для оракл):


обратите на организацию связи: references TABLE1 (ID) on delete cascade
обратите внимание на это-  sys_connect_by_path и на это - select level




Это сообщение отредактировал(а) DimW - 5.10.2009, 07:46

DimW, я вот тоже нашел http://www.opennet.ru/base/dev/hierarchy_sql.txt.html  только там под Interbase, заточить по-моему можн под MySQL


в MyISAM таблицых в MySQL такого нету...
у меня сейчас таблица именно такая

спасибо, посомтрю, с Oracle не работал никогда, буду иметь ввиду на PgSQL... или на innodb

====

я вот как раз хотел оптимизировать DELETE на MySQL
(кроме временных таблиц - это сделал)

Есть таблица составных деталей с "древесной" структурой, т.е. код/код предка/название, например:

Как в такой таблице красиво сделать рекурсивное удаление всех потомков при удалении записи (чтобы при удалении детали №4 удалились детали №5,6,7)? 


вот я это нашел... http://forum.foxclub.ru/read.php?29,400359,400507 только там под Interbase, заточить по-моему можн под MySQL

например на  Visual Foxpro:


но как написать это на MySQL, например, на триггерах или процедурах?

не могу понять как это сделать вообще, путаюсь...




Это сообщение отредактировал(а) gcc - 5.10.2009, 08:34

Oracle не выводит кол-во реально удаленных записей? Ведь реально было удалено 7 записей.

на триггерах можно примерно так:

что такое MyISAM я не знаю, но дока по mysql говорит что каскадное удаление есть: http://dev.mysql.com/doc/refman/5.1/en/inn...onstraints.html

FireBird пропускает такие триггеры

при такой организации связи нет.

MyISAM - это технология(в документации mysql называется "движком" - Engine), которая определяет особенности хранения данных и работы с ними. Определяется в отдельности на каждую таблицу. С точки зрения SQL-запроса является прозрачным. Но накладывает ограничения. К примеру, MyISAM не поддерживает транзакции и внешние ключи.

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

skyboy, может и по поводу каскадного удаления прояснишь, тоже не поддерживается?

DimW,  вот тут вот есть не много

http://ru.wikipedia.org/wiki/MyISAM
http://xpoint.ru/forums/computers/dbms/mys...ead/36704.xhtml

в MyISAM есть fulltext index поиск можно сделать с релевантностью

не отвечай в доке ясно написано: 



gcc, так что можете использовать в innodb каскадное удаление.

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

ага, спасиб, в полне достаточно что бы больше не лажать предлогая решение пробмы.

Добавлено через 7 минут и 43 секунды
походу из плюсов MyISAM только быстрое чтение и быстрая крос-переносимость.

про внешние ключи забыл вообще...

тогда поставлю innodb