Меню
Что нового?

Сохранение позиции ветки дерева.

А попробуй залить в массив, а над ними существует уже уйма стандартных алгоритмов. Вообще зачем СУБД мучать деревьями или графами...
 
kyzma

не умничай :-) тебе не идет
надо делать прямо а не через одно место
 
white phoenix
А о чем ты, собсно, спрашиваешь? Если ты хочешь знать, как хранить деревья - ссылки тебе уже дали. Если хочешь использовать свой метод... ну, по-моему, при росте объемов это может выйти боком.
 
crocodile2u
> А о чем ты, собсно, спрашиваешь?
Я спросил и получил ответ (ссылку) в первом же посте. У матросов нет вопросов :)
Итог:
При больших объемах несомненно нужно использовать nested sets, но в моей задачке, nested sets это как из пушки по комарам, поэтому я написал свой простенький механизм который меня вполне устраивает.
 
crocodile2u
white phoenix "изобрел" способ, который я условно назвал "Номер строки и уровень вложенности"
http://phpclub.ru/faq/Tree/OtherLl

white phoenix
Люди могут говорить "так проще", потому что они не могут разобраться с тем, что действительно проще. Фраза "так проще" является оправданием к тому, чтобы не разбираться с незнакомым материалом. Но результат такого неразбирательства состоит в том, что потом, когда программу нужно будет сопровождать, головной боли хватит всем и на долго.

Вложенные множества - это не "из пушки по комарам". Вложенные множества - это обычный способ.

white phoenix
crocodile2u
kvf77
Этот способ имеет право на существование, поскольку с его помощью действительно возможно хранить иерархическую структуру. Однако это один из самых неисследованных способов. Вероятно, этот способ является неисследованным, потому что он кажется совсем плохим.

white phoenix
В качестве тренировачного упражнения, не хочешь произвести исследование этого способа и сравнить его с другими способами? Я могу помочь методически - расскажу, с каких сторон нужно сравнить, чтобы сравнение было достаточно полным.

-~{}~ 20.12.05 14:11:

white phoenix
При больших объемах несомненно нужно использовать nested sets
Нажмите для раскрытия...
Если ты читал внимательно, то, вероятно, понял, что "сомненно". Очень даже как "сомненно". :-)
 
white phoenix
1. Хорошо бы записать запросы (или скрипты на РНР, если задачу одним запросом решить невозможно) для выполнения следующих основных операций:
- выборка всех непосредственных детей
- выборка поддерева
- выборка всех родителей
- добавление вершины
- удаление вершины вместе с поддеревом
- перемещение вершины вместе с поддеревом

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

2. Для каждого запроса сравнить с соответствующими запросами в двух других основных способах - с запросами во вложенных множествах и с запросами в списках смежностей. Сравнение нужно производить с точки зрение "там - лучше (проще, быстрее, понятнее) тем-то и тем-то", "здесь - лучше (проще, быстрее, понятнее) тем-то и тем-то", "там - хуже (сложнее, медленнее, непонятнее) тем-то и тем-то", "здесь - хуже (сложнее, медленнее, непонятнее) тем-то и тем-то".

3. Если для каких-то запросов в исследуемом методе ты пишешь "здесь - быстрее", то хорошо бы запрограммировать соответствующие способы и сравнить время фактического выполнения запросов.

4. Если ты не можешь написать, что "здесь - быстрее", то хорошо особо пристальное внимание уделить вопросам "здесь - понятнее (и там - непонятнее) тем-то и тем-то", "здесь - проще (и там - сложнее) тем-то и тем-то".
 
Popoff
На самом деле я заинтересовался этим способом. Поначалу свосем было "не въехал" - подумал, что white phoenix чего-то недоговаривает. Потом понял, что хранить дерево так - можно.

Вот только остаются вопросы - как быть с выборками? Конкретно вопросы я тоже обозначил. И если на них отвечать, то, имхо, на уровне SQL. Всякие там "разборки с помощью пехапы" - ну, это, имхо просто аргумент contra использования данного способа. Не дай бог окажется еще, что для того, чтобы выбрать под-ветку узла, заданного по ID, придется выбирать все дерево целиком...
 
Сравнение на "проще", "понятнее" можно производить только рассматривая конкретные запросы на SQL или программу на РНР. Для этого располагаем рядом запрос и программу и сравниваем их построчно.

Например, если для какой-то операции во вложенных множествах нужно писать скрипт на РНР, а в исследуемом способе - все можно сделать простым SQL-запросом, то это есть плюс в сторону исследуемого способа. Если в исследуемом нужно использовать два запроса или дополнительную группировку, когда в другом способе - один или без группировки, то это минус исследуемого способа.

-~{}~ 20.12.05 14:37:

crocodile2u
можешь помочь white phoenix в исследовании. Поделитесь пополам запросами и помогайте друг другу в их составлении и проверке их корректности.
 
Посмотрим. Новый год близок. Время горячее - страдная пора практически. я и на форуме-то стал реже бывать. сегодня вот только разошелся :))
 
Войдите или зарегистрируйтесь для ответа.
Сверху