Форум: "Базы";
Текущий архив: 2006.03.19;
Скачать: [xml.tar.bz2];
ВнизКак отсортировать дерево в оракле ? Найти похожие ветки
← →
ANB © (2006-01-24 23:08) [0]Имеем дерево :
create table Tree
(
ID number,
Parent_ID number,
ElemName varchar2(255)
)
Имеем запрос к дереву (достать ветку) :
select *
from Tree
start with ID = :Start_ID
connect by Parent_ID = prior ID
Вопрос - как заставить оракл отсортировать группы и элементы внутри групп по алфавиту, не ломая дерево ?
← →
Johnmen © (2006-01-25 00:09) [1]Нереально.
← →
ANB © (2006-01-25 00:11) [2]
> Johnmen © (25.01.06 00:09) [1]
Если повесить индекс (Parent_ID, ElemName), то оракл вертает все отсортированным. Но стоит создать еще один индекс с Parent_ID, как все может сломаться.
← →
Sergey13 © (2006-01-25 09:12) [3]2[2] ANB © (25.01.06 00:11)
Если указать хинтом нужный индекс, то наличие другого сказываться не должно вроде.
В 9 вроде появилась фича для сортировки в дереве.
← →
ANB © (2006-01-25 09:14) [4]
> Если указать хинтом нужный индекс, то наличие другого сказываться
> не должно вроде.
> В 9 вроде появилась фича для сортировки в дереве
Про фичу в 9 и еще больше фичей в 10 мне уже сказали на SQL.ru. Но у меня 8. А вот с хинтом . . . По идее то оракл должен 2 индекса использовать - по ID и по Parent_ID.
← →
Sergey13 © (2006-01-25 09:30) [5]2[4] ANB © (25.01.06 09:14)
Насколько я понимаю, для доступа к одной таблице в каждом отдельном запросе может быть выбран только один индекс. Полей в нем (индексе) может быть несколько, но сам индекс один.
Попробуй сделать индекс-организованную таблицу - может это поможет.
← →
ANB © (2006-01-25 11:48) [6]
> Sergey13 © (25.01.06 09:30) [5]
Это для обычной выборки. Когда я писал процедуру обхода дерева на клиппере наилучшие результаты дало использование 2-х индексов. Для эксперимента я завел оба их в оракле и скорость connect by на большом дереве резко увеличилась.
← →
Sergey13 © (2006-01-25 11:58) [7]2[6] ANB © (25.01.06 11:48)
> Для эксперимента я завел оба их в оракле и скорость connect by на большом дереве резко увеличилась.
А сортировка осталась?
Для увеличения скорости я делал денормализацию. Дополнительное поле, которое содержит коренного родителя. Т.е. у всей ветки есть общий признак. У корневой записи Ид и это поле одинаковы. Потом делал не
from table, а from (select * from table where id_main_parent=:id), а к результату уже connect by. Скорость вырастала на порядки.
← →
Desdechado © (2006-01-25 12:04) [8]наличие хинта (согласно доков) НЕ ОБЯЗЫВАЕТ оракл его использовать
оракл может использовать что-то еще, если хинт покажется ему малоперспективным
← →
Sergey13 © (2006-01-25 12:13) [9]2 [8] Desdechado © (25.01.06 12:04)
Спорить не буду, лень искать, но сомнительно это. Иначе зачем он (хинт) тогда вообще нужен. Он может быть проигнорирован только в случае, если такого индекса (из хинта) нет физически.
ИМХО.
← →
ANB © (2006-01-25 12:47) [10]
> Sergey13 © (25.01.06 11:58) [7]
Сортировка осталась. Но если завести еще один индекс на Parent_ID, то она ломается (не всегда).
← →
Desdechado © (2006-01-25 12:52) [11]> сомнительно это
цитирую Oracle9i Database Performance Tuning Guide and Reference
For example, if you have a very complex query, which consists of many table joins, and if you specify only the INDEX hint for a given table, then the optimizer needs to determine the remaining access paths to be used, as well as the corresponding join methods. Therefore, even though you gave the INDEX hint, the optimizer might not necessarily use that hint, because the optimizer might have determined that the requested index cannot be used due to the join methods and access paths selected by the optimizer.
← →
Sergey13 © (2006-01-25 13:12) [12]2[11] Desdechado © (25.01.06 12:52)
>that the requested index cannot be used due to the join methods and access paths selected by the optimizer.
Т.е. не может быть использован, вступает в противоречие с условиями сложного запроса. Если НЕ вступает, но может быть менее эффективен с точки зрения СВО, все равно будет использоваться хинтовый индекс.
Я так думаю! (с) Мимино
← →
Desdechado © (2006-01-25 13:21) [13]чего спорить?
requested index cannot be used due to the join methods and access paths selected by the optimizer.
оптимизатор может решить, что этот индекс ему не подходит, т.к. он избрал другой (более эффективный) путь
← →
Petr V. Abramov © (2006-01-25 13:55) [14]В 9-ке есть волшебное слово order sibling by. В более ранних версиях - см [2]
← →
ZeroDivide © (2006-01-26 09:45) [15]Попробовал в девятке (9.2.0)
> order sibling by
не сработало. Как это юзать?
← →
roottim © (2006-01-26 13:07) [16]Oracle9i SQL Reference
Release 2 (9.2)
Part Number A96540-02SELECT last_name, employee_id, manager_id, LEVEL
FROM employees
START WITH employee_id = 100
CONNECT BY PRIOR employee_id = manager_id
ORDER SIBLINGS BY last_name;
LAST_NAME EMPLOYEE_ID MANAGER_ID LEVEL
------------------------- ----------- ---------- ----------
King 100 1
Cambrault 148 100 2
Bates 172 148 3
Bloom 169 148 3
Fox 170 148 3
Kumar 173 148 3
Ozer 168 148 3
Smith 171 148 3
De Haan 102 100 2
Hunold 103 102 3
Austin 105 103 4
Ernst 104 103 4
Lorentz 107 103 4
Pataballa 106 103 4
Errazuriz 147 100 2
Ande 166 147 3
Banda 167 147 3
← →
ZeroDivide © (2006-01-26 20:44) [17]SIBLINGS
^ ...
← →
Petr V. Abramov © (2006-01-26 22:36) [18]> ZeroDivide © (26.01.06 20:44) [17]
ну ладно, через десяток постов с полслова друг друга понимать будем :)))
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2006.03.19;
Скачать: [xml.tar.bz2];
Память: 0.5 MB
Время: 0.015 c