Связывание таблиц

← →
}|{yk © (2005-02-18 12:14) [0]

Допустим, у нас есть таблица aaa с 2 внешними ключами ft_field и ft_field2, которые ссылаются на pk_field таблицы bbb.
Как сделать выборку из этих таблиц, чтобы не дважды связывать с таблицей bbb, т.е. не делать
select a.field1, a.ft_field, a.ft_field2, b.name_field FName, c.name_field SName from aaa a, bbb b, bbb с where a.ft_field = b.pk_field and a.ft_field = c.pk_field
?

← →
Johnmen © (2005-02-18 12:17) [1]

Никак.

← →
}|{yk © (2005-02-18 12:22) [2]

А чтобы индекс дважды использовался, а не только в 1 случае (СУБД - Oracle)?

← →
Johnmen © (2005-02-18 12:26) [3]

А он не используется дважды ?
Покажи план запроса....

← →
}|{yk © (2005-02-18 12:28) [4]

Ну, реальный запрос такой
SELECT a.bank_id, a.plat_id, a.line_id, case when h.mem_desc is null then h.mem_name else h.mem_desc end line_name, a.line_id_to, case when l.mem_desc is null then l.mem_name else l.mem_desc end line_to_name , a.summa bank_sum, b.nds_sum, a.commentar koment, b.plat_date, b.plat_nom, b.kontr_id, g.kontr_name, b.koment plat_koment, b.deb_kred, b.rs_id, c.mem_name cust1, d.mem_name cust2, e.rs_name, f.mem_desc cust3,j.mem_name unit, a.avans_pogash , a.unit_id FROM app_bank a, app_plateg b, cust1 c, cust2 d, app_rs e, cust3 f, app_kontragent g, line h, unit j, app_plat_status k, line l WHERE a.plat_id = b.plat_id AND k.suma=k.summ_plateg AND a.cust1_id = c.mem_id AND a.cust2_id = d.mem_id AND b.rs_id = e.rs_id AND a.cust3_id = f.mem_id AND b.kontr_id = g.kontr_id AND a.line_id=h.mem_id AND a.unit_id=j.mem_id and a.plat_id = k.plat_id AND a.line_id_to = l.mem_id(+)
План такой
SQL Statement from editor: SELECT a.bank_id, a.plat_id, a.line_id, a.line_name, a.line_id_to, a.line_to_name, a.bank_sum, a.nds_sum, a.koment, a.plat_date, a.plat_nom, a.kontr_id, a.kontr_name, a.plat_koment, a.deb_kred, a.rs_id, a.cust1, a.cust2, a.rs_name, a.cust3, a.unit, a.avans_pogash, a.unit_id FROM app_view_bank a ------------------------------------------------------------ Statement Id=5 Type=HASH JOIN Cost=851501 TimeStamp=18-02-05::11::27:37 (1) SELECT STATEMENT CHOOSE Est. Rows: 16 023 655 630 Cost: 1 321 340 448 (32) NESTED LOOPS Est. Rows: 16 023 655 630 Cost: 1 321 340 448 (29) HASH JOIN OUTER Est. Rows: 1 306 986 593 Cost: 14 353 855 (27) HASH JOIN Est. Rows: 106 605 758 Cost: 1 607 324 (2) TABLE ACCESS FULL ENERGY.APP_KONTRAGENT [Not Analyzed] (2) Est. Rows: 736 Cost: 2 Tablespace: ENERGY (26) HASH JOIN Est. Rows: 14 484 478 Cost: 851 501 (3) TABLE ACCESS FULL ENERGY.UNIT [Not Analyzed] (3) Est. Rows: 164 Cost: 1 Tablespace: ENERGY (25) HASH JOIN Est. Rows: 8 831 999 Cost: 789 882 (4) TABLE ACCESS FULL ENERGY.CUST3 [Not Analyzed] (4) Est. Rows: 164 Cost: 1 Tablespace: ENERGY (24) HASH JOIN Est. Rows: 5 385 365 Cost: 681 354 (5) TABLE ACCESS FULL ENERGY.APP_PLATEG [Analyzed] (5) Blocks: 179 Est. Rows: 7 681 of 7 681 Cost: 28 Tablespace: ENERGY (23) HASH JOIN Est. Rows: 7 011 281 Cost: 7 402 (13) VIEW ENERGY.APP_SUMMA_ON_BANK Est. Rows: 14 755 Cost: 365 (12) SORT GROUP BY Est. Rows: 14 755 Cost: 365 (11) VIEW ENERGY.APP_SUM_ON_BANK Est. Rows: 14 755 Cost: 187 (10) SORT UNIQUE Est. Rows: 14 755 Cost: 187 (9) UNION-ALL (7) SORT GROUP BY Est. Rows: 7 074 Cost: 139 (6) TABLE ACCESS FULL ENERGY.APP_BANK [Analyzed] (6) Blocks: 84 Est. Rows: 7 074 of 7 074 Cost: 13 Tablespace: ENERGY (8) UNIQUE INDEX FAST FULL SCAN ENERGY.APP_PLATEG_PK [Not Analyzed] Est. Rows: 7 681 Cost: 4 (22) HASH JOIN Est. Rows: 47 518 Cost: 682 (14) TABLE ACCESS FULL ENERGY.CUST2 [Not Analyzed] (14) Est. Rows: 82 Cost: 1 Tablespace: ENERGY (21) HASH JOIN Est. Rows: 57 949 Cost: 467 (15) TABLE ACCESS FULL ENERGY.CUST1 [Not Analyzed] (15) Est. Rows: 82 Cost: 1 Tablespace: ENERGY (20) HASH JOIN Est. Rows: 70 669 Cost: 239 (18) HASH JOIN Est. Rows: 999 Cost: 42 (16) TABLE ACCESS FULL ENERGY.APP_RS [Analyzed] (16) Blocks: 1 Est. Rows: 13 of 13 Cost: 1 Tablespace: ENERGY (17) TABLE ACCESS FULL ENERGY.APP_PLATEG [Analyzed] (17) Blocks: 179 Est. Rows: 7 681 of 7 681 Cost: 28

← →
}|{yk © (2005-02-18 12:28) [5]

Tablespace: ENERGY (19) TABLE ACCESS FULL ENERGY.APP_BANK [Analyzed] (19) Blocks: 84 Est. Rows: 7 074 of 7 074 Cost: 13 Tablespace: ENERGY (28) TABLE ACCESS FULL ENERGY.LINE [Not Analyzed] (28) Blocks: 84 Est. Rows: 1 226 of 7 074 Cost: 3 Tablespace: ENERGY (31) TABLE ACCESS BY INDEX ROWID ENERGY.LINE [Not Analyzed] (31) Blocks: 84 Est. Rows: 1 226 of 7 074 Cost: 1 Tablespace: ENERGY (30) UNIQUE INDEX UNIQUE SCAN ENERGY.PK_LINE [Not Analyzed] Est. Rows: 1 226

← →
Johnmen © (2005-02-18 12:34) [6]

Не, ну не надо было так распаляться...:)))

Здесь есть VIEW ?

← →
}|{yk © (2005-02-18 12:42) [7]

Да

← →
Johnmen © (2005-02-18 12:54) [8]

При соединении с VIEW индексы не используются...
Больше ничего не могу сказать.
Кстати, на основании чего ты решил, что [2] ?

Уряяяя! Убрал вьюху из запроса, стоимость запроса стала в 1000 раз меньше.

Если l - таблица небольшая, часто помогает следуюющее:
сделайте запрос вложенным, во внутреннем оставьте все inner join, а на внешнем свяжите с той самой таблицей line. Может, и view убирать не придется, его же, наверное, не просто так создавали.

2[9] }|{yk © (18.02.05 13:04)
>Уряяяя! Убрал вьюху из запроса, стоимость запроса стала в 1000 раз меньше.
Стоимость запроса Cost - это внутренние "попугаи" оптимизатора. Если при том же плане разный Cost - это ничего не значит.
Что-то фул-сканов многовато (хотя я поверхностно глядел). Статистику собираете регулярно.

Связывание таблиц Найти похожие ветки