|
Как избавиться от функции с иерархическим запросом.
|
|||
---|---|---|---|
#18+
Есть таблица, ссылающаяся на саму себя и таблицу дополнительных параметров. Требуется достать значение параметра для корня ветки. На всякий случай проиллюстрирую: Код: plaintext 1. 2. 3. 4. 5. 6.
Так вот, собственно, можно ли как-то заставить это работать быстрее, или можно как-то по-другому сделать? Вот набросал тестовый пример. Таблица node наполнена таким количеством данных, которое соответствует реальному количеству данных в боевых таблицах. Код: 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. 67. 68. 69. 70. 71. 72. 73.
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
работает ~1 минуты :(. Хотелось бы ускориться хотя бы до ~10-15 секунд. З.Ы. Используется Oracle 10XE ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2012, 14:03 |
|
Как избавиться от функции с иерархическим запросом.
|
|||
---|---|---|---|
#18+
aleksandy или можно как-то по-другому сделать? Например: 0. У корней хранить NULL в node_id. 1. В запросе функции соединять с таблицей параметров результат поиска корня: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
2. Убрать обработку NO_DATA_FOUND в функции. Или хотя бы возвращать NULL. 3. Последний шаг: денормализовать структуру, добавив поле root_id в таблицу nodes. Или создать отдельную таблицу из двух полей (root_id, node_id). При изменении корня не забывать её обновлять. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2012, 15:07 |
|
Как избавиться от функции с иерархическим запросом.
|
|||
---|---|---|---|
#18+
При заранее известной предельной глубине вложенности можно вообще отказаться от connect by, заменив ссылку ключем классификатора. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2012, 15:17 |
|
Как избавиться от функции с иерархическим запросом.
|
|||
---|---|---|---|
#18+
suPPLer, 0. Уже поздно, слишком много кода, который может поломаться, если в поле будет null. Я знаю, что это нехорошо, но такое вот тяжёлое наследие. 1. А вот за это спасибо, для 1 записи средняя скорость с 2-2.5 секунд возросла до 0.016-0.2 2. В оригинальной функции я, естественно, возвращаю null при отсутствии данных. Чего-то я не забыл про return в тестовом примере. :) 3. Для того чтобы сделать это, всё равно придется искать этот root_id, а это слишком долго, я не могу остановить приложение так надолго. Признаться честно, это была моя первая мысль. andrey_anonymous, фишка как раз в том, что уровень вложенности никак не ограничен, и пользователи могут сделать его сколь угодно большим. Хотя в 90% случаев глубина не превышает 3 уровней. Всем спасибо, тему можно закрывать ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2012, 07:57 |
|
|
start [/forum/search_topic.php?author=uchetik&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
others: | 10650ms |
total: | 10802ms |
0 / 0 |