|
|
|
Рекурсивный запрос по дереву от листьев к корню.
|
|||
|---|---|---|---|
|
#18+
Добрый день! Задача следующая. В базе данных хранится некий двудольный (два типа вершин) ориентированный граф. Структура графа такова, что вершины типа 2 (квадратик) связывают вершины типа 1 (кружочек) всегда с соотношением 2 к 1. На рисунке я отобразил граф в минимальном варианте, но предполагается, что он может состоять из сотен (может быть тысяч) элементов, которые каким-либо образом связаны. Прикладываю картинку графа. Схема тестовой базы данных. Код: 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. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. Проблема с составлением рекурсиваного запроса при движении от листьев к корню. Собственно рекурсивный запрос: Код: 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. 32. 33. 34. Результат idleft_idleft_nameright_idright_nametype_idtype_nameresult_idresult_namedepth11"1_1"2"1_2"1"2_1"7"1_7"123"1_3"4"1_4"2"2_2"8"1_8"135"1_5"6"1_6"1"2_1"9"1_9"147"1_7"8"1_8"2"2_2"10"1_10"2510"1_10"9"1_9"1"2_1"11"1_11"2510"1_10"9"1_9"1"2_1"11"1_11"3 Как видно, происходит дублирование элемента с идентификатором 5. Вот с этим дуболированием я и пытаюсь бороться. Я понимаю, почему это происходит. В офф. доке доходчиво написано как реализован рекурсивный запрос в PG и как он выполняется. Если этот запрос переписать от корня, то проблем нет. Но при движении от корня неправильно вычисляются номера уровней (depth), которые далее необходимы для последующего анализа структуры такого графа. Если убрать depth, то тоже все в порядке (от листьев к корню). Но depth нужен, опять же для последующего анализа. Собственно вопрос: Сталкивался ли кто-либо с такой задачей?? И не могли бы вы направить решение в праивльное русло?? Что почитать?? Что посмотреть?? Я уже всю голову сломал, но никак не могу придумать, как бы составить такой рекурсивный запрос. Попытки что либо выудить из гугля приводили к примерам, но без полной аналогии представления дерева и соответственно практически не приблизили меня к ответу. Опыт составления запросов у меня есть, но возможно не такой прокаченный, чтобы осилить задачу. В примерах мне попадались "крутые" рекурсвиные запросы с двумя и тремя подзапросами в WITH, но я еще не пришел для себя к решению, как это поможет для моей схемы данных. Сейчас "колдую" над вариантом, когда через итерацию протаксиваются агрегаты идентификаторов уже пройденных вершин (id_result), чтобы пытаться убирать дубликаты, но пока не очень выходит, ибо движение по дереву идет от листьев к корню. Кстати сама схема хранения может быть произвольно изменена, если это позволит решить проблему с рекурсивным запросом. Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 10:20 |
|
||
|
Рекурсивный запрос по дереву от листьев к корню.
|
|||
|---|---|---|---|
|
#18+
Пока что остановился на костыле: дополнительным запросом отсекаю "дубликаты" с немаксимльным значением depth, но подозреваю, что есть более красивое решение в один запрос, которое решит эту задачу более эффективно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 10:51 |
|
||
|
Рекурсивный запрос по дереву от листьев к корню.
|
|||
|---|---|---|---|
|
#18+
grgdvo, мне не очень понятна специфика хранения информации, которую вы предприняли. исходя из картинки, у вас 5 квадратиков, но в исходных данных у вас их всего 2. Как так? Один и тот же квадратик одновременно находится на разных уровнях? не очень понятно почему кружки 1-5 и 1-6 на схеме находятся в самом верху, когда они по идее должны быть на уровне 1-7 и 1-8 что вы понимаете под depth? исходя из выходных данных могу предположить что это уровень квадратика, то есть кружки игнорируем и считаем только вложенность квадратиков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 11:28 |
|
||
|
Рекурсивный запрос по дереву от листьев к корню.
|
|||
|---|---|---|---|
|
#18+
grgdvo, многабукав, нечитал пока вижу, что если задача хранить структуру -- то квадратики там лишние. у вас обычное бинарное дерево. пририсуйте квадратики сбоку (если всё еще нужны), а ссылки -- непосредственно в бинарном дереве. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 11:56 |
|
||
|
Рекурсивный запрос по дереву от листьев к корню.
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2015, 12:38 |
|
||
|
Рекурсивный запрос по дереву от листьев к корню.
|
|||
|---|---|---|---|
|
#18+
grgdvo, node2 - не узлы "второго типа", а справочник "тип связи" между узлами node1. таблицу логично переименовать в link_type. а что хотите вытащить-то? список всех узлов вместе с полным путем до корня от каждого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2015, 12:51 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=113&tid=1998105]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 362ms |

| 0 / 0 |
