MaterializedPath

[zk]

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

 

[zarus]

Автор оригинала: zk
Тоже вариант!
Но иногда лучче подумать сразу об этом =)) А то потом рефакторить запаришься! =)
...
Я бы с удовольствием. Но не вижу реального применения сего в своих проектах. Ну нету у меня таких задач.

1. Рефакторить SQL-запросы? о.О Синтаксис то-бишь... ню-ню...
2. Советов надавал, и сразу убежал...

2Renny
Используй для получения потомков узла выброку вида
SELECT ... WHERE ... like '$parent_path<символ разделения>$parent_id<символ разделения>%'
где $parent_path получается запросом
SELECT ... WHERE ... = $parent_id

 

[crocodile2u]

[offtop]
su1d
У метода Тропашко коэффициенты растут не только при увеличении глубины дерева - но и при увеличении кол-ва узлов на уровне. Реально с применением MySQL (поля BIGINT) и php(--enable-bcmath) мне удалось достичь лишь очень ограниченных результатов. Может быть, Oracle позволяет сделать что-то лучшее? Хотя диапазон целых чисел, само собой, ограничен и там.
[/offtop]

 

[su1d]

crocodile2u
ты прав. при росте дерева в ширину тоже наблюдается значительный рост коэффициентов, однако, не настолько резкий, как при росте в глубину.

поля BIGINT не имеют особого смысла на 32-битных архитектурах, т.к. напрочь убьётся скорость работы с.
и даже на 64-битных ты получишь лишь несколько дополнительных уровней данных вглубь.

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

в итоге ты становишься перед лицом этакого trade-off'а:
- либо работаешь с огромными целыми числами, для которых слишком быстро начинает не хватать разрядности;
- либо работаешь с вычислениями с плавающей точкой, что на любом серьёзном наборе данных очень ощутимо замедляет обработку.

 

[Renny]

2 zarus
Это я думаю только еще больше привяжет реализацию к MySQL, я с другими БД не знаком, точно не скажу.

 

[crocodile2u]

su1d
Я использовал BIGINT и bcmath только чтобы посмотреть на алгоритм в действии и быстренько убедиться в его сугубо теоретической природе Получается, что алгоритм, который был призван ускорить работу с большими деревьями (ведь на маленьких вообще не нужно всех этих извратов) - реально может работать только с очень малыми объемами данных...

А рост коэффициентов "вширь" - в общем-то тоже экспоненциальный - посмотри на рутовые узлы: 3/2 - 3/4 - 3/8... Да и сама идея - каждая рутовая ветка является в два раза уменьшенной копией предыдущей - стало быть все деноминаторы нужно будет умножить на два (ну, не все так просто, но для выявления общей картины достаточно)

 

[su1d]

crocodile2u
похоже, что ты говоришь о механизме из первой статьи Тропашко.
я же реализовывал алгоритм то ли из третьей, то ли из четвёртой.
там рост коэффициентов не настолько резкий.

 

[crocodile2u]

su1d
Наверное. Надо посмотреть, что там происходит с этми алгоритмом.