|
Обход дерева
|
|||
---|---|---|---|
#18+
Наставьте на путь истины Есть таблица с деревянной структурой Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
По некоторому заданному узлу надо получить всех его детей с "полными именами" и суммами поля Val ну как-то вот так Данные Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Надо получить для узла 2 (code=2) вот такой результат Код: plaintext 1. 2. 3. 4. 5. 6. 7.
получил я такой результат следующим запросом Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
результат то меня устраивает, однако запрос этот мне совсем не нравится, ощущение такое что я что-то недопонимаю и что можно сделать проще :( ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 18:17 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
m7m, что именно не нравится? В трёшке можно упростить если оконными функциями воспользоваться. Внутри рекурсивной части CTE всё равно агрегаты считать нельзя ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 18:31 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
m7m> VAL SUM_VAL 2 0 A2 2 464 Я в детали твоих чисел и запроса не вникал, но попробуй что-то упростить за счет агрегатов - не только Sum, но и List(..., '/'). Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 18:48 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
Симонов Денисm7m, что именно не нравится? В трёшке можно упростить если оконными функциями воспользоваться. Внутри рекурсивной части CTE всё равно агрегаты считать нельзя Не нравится что обход дерева идет фактически два раза, хочется за один проход все сделать Не нравится что в Tree_2 идет расчет сумм по всей таблице, а хотелось-бы только для той части которая соответствует заданному узлу (сообразить как это сделать не смог) зы. FB 2.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 19:04 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
m7m, а зачем ты второе раз древо строишь, первым два раза нельзя воспользоваться? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 19:58 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
m7m, ну можно типа упростить да такого, но не уверен что это будет лучше Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 20:15 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
m7m, сам подход теоретически неправильный, на больших деревьях будет нагружать сервер. решение: хранить полный путь в таблице. 1) создаём дополнительное поле PATH BLOB TEXT 2) на триггер BEFORE INSERT OR UPDATE рассчитываем рекурсивным запросом путь и пишем в поле PATH. 3) у нас всегда готов полный путь к ноду дерева. просто несколько миллисекунд при вставке/обновлении записи в деревянную таблицу пользователь не заметит. а при обходе больших деревьев (например, при подготовке визуализации деревянной таблицы-справочника) расчет пути "на лету" будет дико тупить. --- задача решена при условии, что на размер базы и место на диске заказчика мы тупо забиваем. пусть покупают нормальные винты. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 21:12 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
PEAKTOP, а теперь сменим родителя узлу с кучей дочерних узлов.... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 21:39 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
vvvaitа теперь сменим родителя узлу с кучей дочерних узлов.... Чисто чтобы слоники бегали или у тебя есть практическая задача для этой операции? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.04.2019, 22:09 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
не факт, что будет работать быстрее, но по крайней мере не идет полным перебором по всему дереву ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2019, 02:31 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
если такой запрос нужен постоянно, то можно на временной таблице сделать Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2019, 03:17 |
|
Обход дерева
|
|||
---|---|---|---|
#18+
Всем огромное спасибо!!! Симонов Дениса зачем ты второе раз древо строишь, первым два раза нельзя воспользоваться? Ну мягко говоря вчера у меня голова совсем не работала, да и сегодня еще не полный порядок Симонов Денисну можно типа упростить да такого, но не уверен что это будет лучше выглядит гораздо лучше чем мой исходный, однако дерево строится для всей таблицы, что мне не очень нравится причина ->в таблице иного независимых "деревьев" PEAKTOPсам подход теоретически неправильный, на больших деревьях будет нагружать сервер. решение: хранить полный путь в таблице. а при обходе больших деревьев (например, при подготовке визуализации деревянной таблицы-справочника) расчет пути "на лету" будет дико тупить. я бы не был столь категоричен, по крайней мере мне этот вариант не подходит, и проблема у меня не в том чтобы "рассчитать полный путь" Dimitry Sibiryakovvvvaitа теперь сменим родителя узлу с кучей дочерних узлов.... Чисто чтобы слоники бегали или у тебя есть практическая задача для этой операции? Если про смену родителя у узла, то есть, но причина отказа от хранения полного пути у меня не в этом (ну просто по крайней мере до этого момента полный путь меня не интересовал) vvvaitесли такой запрос нужен постоянно, то можно на временной таблице сделать В такой реализации точно не буду, у меня мозг не переварит Код: sql 1.
да еще с триггером after insert or update в котором сидит update ------------------------------------------------------------------------------ Резюме: все пациенты врут (с)Если бы задача была именно такая(один в один) как я написал то я бы остановился на варианте Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Отличается от моего первоначального варианта только тем что второе дерево строится на основании первого Ну а на самом деле поля Val и в помине нет в исходной таблице, и это не одно значение а несколько, и их вычисление достаточно затратно то будет наверное где-то вот так Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
И последнее (пожалуй самое важное) для чего все это затевается Все банально, очередной велосипед с отчетами. Проблема с выборками и группировками, "естественные" выборки и группировки как-бы продуманы и заложены однако периодически возникает требование выдать отчет по некоторой группе объектов ну которые совершенно не можем формализовать (по причине отсутствия в базе нужных для этого характеристик объектов, ну не были нужны они (эти характеристики) для решаемой задачи, да и не будут они нужны потом, через неделю - две такая выборка будет не актуальна) Вот и родилась идея - держите деревянный справочник, вносите туда что хотите и как хотите, а при выдачи отчета укажите требуемую группу и получите данные по требуемым объектам с нужной вам группировкой и итогами и будет вам счастье и мне тоже (если доведу до ума) Еще раз всем спасибо, и простите за столь длинный пост, наболело :( ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2019, 08:21 |
|
|
start [/forum/topic.php?fid=40&gotonew=1&tid=1560728]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
83ms |
get topic data: |
10ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 312ms |
total: | 497ms |
0 / 0 |