Составной первичный ключ и молотилки

Виктор89
Дата: 21.12.2012 17:16:22
Есть рабочая база (проектировал не я, что имеем, то имеем), которая впрочем дорабатывается и оптимизируется (чем я пытаюсь заняться время от времени).
Запросы соответственно обращаются ко вьюшкам,
Проблема в том, что в базе на некоторые таблицы присутствуют составные ключи

обнаружил недавно большое количество молотилок, я поясню,

+
create table f0(id number, f1_id1 number, f1_id2 number, f2_id number);

alter table f0 add constraint f0_pk primary key (ID);

insert into f0(id,f1_id1,f1_id2,f2_id)
select 1,10,10,null from dual union all
select 2,null,null,100 from dual union all
select 3,30,30,200 from dual;

create table f1(id1 number, id2 number);

alter table F1 add constraint f1_pk primary key (ID1, ID2);

insert into f1
values(10,10);

insert into f1
values(30,30);

create table f2(id number);

alter table f2 add constraint f2_pk primary key (ID);

insert into f2
values(100);

insert into f2
values(200);

alter table f0 add constraint f0_fk1 foreign key (f1_id1, f1_id2) references f1 (ID1, ID2);

alter table f0 add constraint f0_fk2 foreign key (f2_id) references f2 (ID);


Oracle 11
select f0.id from f0, f1, f2
where f0.f2_id = f2.id(+)
  and f0.f1_id1 = f1.id1(+)
  and f0.f1_id2 = f1.id2(+)


----------------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     3 |   195 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS OUTER|       |     3 |   195 |     3   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| F0    |     3 |   117 |     3   (0)| 00:00:01 |
|*  3 |   INDEX UNIQUE SCAN| F1_PK |     1 |    26 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("F0"."F1_ID1"="F1"."ID1"(+) AND
              "F0"."F1_ID2"="F1"."ID2"(+))

Видим, F2 в плане нету, а F1 он молотит в холостую зачем-то (потому что PK составной), таких вещей во вьюшках понаписано довольно много.
Вещи очевидные, но oracle их до настоящего момента не поддерживает?

Или с этим можно как-нибудь побороться?

P.S. что-то нагуглить не получилось :(
Изя Кацман
Дата: 21.12.2012 18:09:07
Виктор89
select f0.id from f0, f1, f2
where f0.f2_id = f2.id(+)
  and f0.f1_id1 = f1.id1(+)
  and f0.f1_id2 = f1.id2(+)

Камрад Виктор89,
Ты хочешь, чтобы оптимизатор просматривал только таблицу F0 в етом запросе?

На картинке схема твоих данных
dbms_photoshop
Дата: 21.12.2012 18:16:41
Виктор89
Или с этим можно как-нибудь побороться?
Выбирай то, что необходимо из t1 в скаляре. Соответственно, если эта колонка/колонки которые получаются из скаляра будет/будут закоментированы, то обращения к таблице не будет.

По поводу того, почему он в любом случае обращается к t1 при дэжойне - наверное действительно еще не умеет обрабатывать случаи многоколоночных внешних ключей.
Точно также как если ты изменишь преидкат для t2 на "f0.f2_id = f2.id(+)+0", то всегда будет обращение и к t2.
Оптимизатор далеко не совершенен.
dbms_photoshop
Дата: 21.12.2012 18:21:58
dbms_photoshop
Выбирай то, что необходимо из t1 в скаляре.
Типа такого:
select 
  f0_id/*,
  id,
  t.ku.num1 id1,
  t.ku.num2 id2*/
from
(select 
  f0.id f0_id,
  f2.id,
  (select ku$_objnumpair(id1, id2) from f1 where f0.f1_id1 = f1.id1 and f0.f1_id2 = f1.id2) ku
   from f0, f2
  where f0.f2_id = f2.id(+)) t
Виктор89
Дата: 21.12.2012 19:04:24
Изя Кацман
Виктор89
select f0.id from f0, f1, f2
where f0.f2_id = f2.id(+)
  and f0.f1_id1 = f1.id1(+)
  and f0.f1_id2 = f1.id2(+)

Камрад Виктор89,
Ты хочешь, чтобы оптимизатор просматривал только таблицу F0 в етом запросе?

На картинке схема твоих данных

Да, именно так, очевидно просмотр остальных таблиц здесь избыточен. А нужно это мне, т.к некая избыточность соединений во view, с точки зрения отдельного запроса - это нормально, и при простых внешних ключах проблем нет.

dbms_photoshop, спасибо, попробую в понедельник.
Изя Кацман
Дата: 21.12.2012 19:10:18
Виктор89
некая избыточность соединений во view, с точки зрения отдельного запроса - это нормально...
Ето твое мнение
Мое мнение - это ненормально

Объясни зачем во VIEW эта избыточность нужна?
Виктор89
Дата: 21.12.2012 19:20:12
Изя Кацман,

В одном запросе есть обращение к справочнику, в другом нет, а view нужна, чтобы не дублировать запросы, которые могут быть большими.
Иначе поддерживать все эти запросы становится очень сложно.
Виктор89
Дата: 21.12.2012 19:33:57
Изя Кацман,

В одном запросе есть обращение к справочнику, в другом нет, а view нужна, чтобы не дублировать запросы, которые могут быть большими.
Иначе поддерживать все эти запросы становится очень сложно.
Изя Кацман
Дата: 21.12.2012 19:37:45
Виктор89,
Приведи пример view и запросов
Виктор89
Дата: 21.12.2012 19:38:40
Виктор89,

упс, пост лишний.
Изъясняясь проще, чтобы не соединять бесконечное количество вьюшек и таблиц каждый раз, а только необходимые поля из одной для типичных запросов..