Как на оракле будет выглядеть этот запрос

← →
alex_*** © (2007-06-05 11:57) [0]

есть запрос на T-SQL. Не знаю как переделать под Оракле. Подскажите, кто знает, плз
select ProductName, category_name = (SELECT categoryID FROM Categories c WHERE c.CategoryID = p.CategoryID) from Products p

← →
Desdechado © (2007-06-05 12:00) [1]

Какой-то уродский SQL.
В нормальном виде, наверно, так:
select p.ProductName, p.category_name from Products p, Categories c WHERE c.CategoryID = p.CategoryID

← →
alex_*** © (2007-06-05 12:01) [2]

сделал:
select count(*), td.dictid, (SELECT note from TDICT td1 WHERE td1.dictid=td.dictid) as DICT_NAME, te.objectstateid from timport ti, texport te, TDICT td where te.importid = ti.importid AND ti.dictid = td.dictid GROUP BY td.dictid, te.objectstateid

← →
alex_*** © (2007-06-05 12:06) [3]

join с диктом можно выкинуть, сразу не допер :)

← →
ЮЮ © (2007-06-05 12:08) [4]

> сделал:

Поздравляю, ещё более уродский. Или читаюбельность нв SQL мене важна?

← →
alex_*** © (2007-06-05 12:10) [5]

что не нравится? Регистр? или join надо словами прописать?

← →
alex_*** © (2007-06-05 12:17) [6]

вот еще вариант:
SELECT t.OBJ_COUNT, t.DICTID, td.NOTE, t.objectstateid, te.NAME from TDICT td, TObjectState te, ( SELECT count(*) AS OBJ_COUNT, te.dictid, te.objectstateid from timport ti, texport te where te.importid = ti.importid GROUP BY te.dictid, te.objectstateid ) t where td.DICTID = t.DICTID AND te.objectstateid = t.objectstateid
по мне те же яйца, но сбоку

← →
ЮЮ © (2007-06-05 12:19) [7]

1) и явный jоin нагляднее поквзывает связи между сущностями, чем один из многих операндов в WHERE
2) и подзапрос в каждой записи - лишнее, note также можно при-jоinить где положено - во FROM

select
count(*),
td.dictid,
td.Note as DICT_NAME,
te.objectstateid
from
timport ti
join texport te te.importid = ti.importid
join TDICT td ON ti.dictid = td.dictid
GROUP BY
td.dictid, td.Note, te.objectstateid

← →
alex_*** © (2007-06-05 12:28) [8]

в первоначальном варианте план выполнения проще. Щас лягушку поставлю, посмотрю план выполнения более детально

← →
Desdechado © (2007-06-05 12:30) [9]

> план выполнения проще
FULL TABLE SCAN - самый простой план, не так ли?

← →
alex_*** © (2007-06-05 12:59) [10]

> FULL TABLE SCAN - самый простой план, не так ли?

и во многих случаях самый эффективный...

вот 2 плана:

из [7]
Plan SELECT STATEMENT CHOOSE 10 SORT GROUP BY 9 NESTED LOOPS 7 NESTED LOOPS 4 NESTED LOOPS 1 TABLE ACCESS FULL WSPS.TEXPORT 3 TABLE ACCESS BY INDEX ROWID WSPS.TOBJECTSTATE 2 INDEX UNIQUE SCAN UNIQUE WSPS.TOBJECTSTATE_PK 6 TABLE ACCESS BY INDEX ROWID WSPS.TDICT 5 INDEX UNIQUE SCAN UNIQUE WSPS.TDICT_PK 8 INDEX UNIQUE SCAN UNIQUE WSPS.TIMPORT_PK

для

SELECT
count(*),
te.dictid,
(SELECT note from TDICT td1 WHERE td1.dictid=te.dictid) as DICT_NAME,
te.objectstateid,
(SELECT "NAME" FROM TOBJECTSTATE tos WHERE tos.objectstateid = te.objectstateid) AS OBJECT_STATE
from timport ti, texport te
where te.importid = ti.importid
GROUP BY te.dictid, te.objectstateid
:
Plan SELECT STATEMENT CHOOSE 2 TABLE ACCESS BY INDEX ROWID WSPS.TDICT 1 INDEX UNIQUE SCAN UNIQUE WSPS.TDICT_PK 4 TABLE ACCESS BY INDEX ROWID WSPS.TOBJECTSTATE 3 INDEX UNIQUE SCAN UNIQUE WSPS.TOBJECTSTATE_PK 8 SORT GROUP BY 7 NESTED LOOPS 5 TABLE ACCESS FULL WSPS.TEXPORT 6 INDEX UNIQUE SCAN UNIQUE WSPS.TIMPORT_PK

по моему, 2-й план эффективнее. Поскольку к таблицам справочников обращается уже на последнем этапе, когда лишние записи отсекли

← →
Desdechado © (2007-06-05 13:13) [11]

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

← →
alex_*** © (2007-06-05 13:30) [12]

> Ты сначала статистику по таблицам, индексам и железу собери,
> потом уже эффективность анализируй.

ну это ты уже в дебри лезешь, имхо.

зачем в терминах оракла? недостаточно в терминах БД - обращение к таблицам? План выполнения он и в африке план выполнения. Что для оракла, что для MS SQL. Чем раньше отсечем ненужные записи и ненужные обращения к ним, тем лучше.
В конечной вьюхе я этот запрос заменил на select from select, что действительно нагляднее, на мой взгляд.

← →
Desdechado © (2007-06-05 14:07) [13]

> План выполнения он и в африке план выполнения
Карта - она всегда карта. Вот только на средневековых картах белых пятен и ошибок больше, чем правильных данных. Но ведь карта же! Плыви, ищи свою Индию.

← →
alex_*** © (2007-06-05 15:48) [14]

> Карта - она всегда карта. Вот только на средневековых картах
> белых пятен и ошибок больше, чем правильных данных. Но ведь
> карта же! Плыви, ищи свою Индию.

словоблудство какое-то....

← →
Кщд © (2007-06-06 06:53) [15]

> словоблудство какое-то....

Вы извините, но словоблудие - это Ваши планы запросов, ибо ни мощности, ни стоимости, ни физического и логического i/o

Народ, а как получить подробный план выполнения для Oracle 9?

explain plan for SELECT .....
и последующий анализ plan_table не дает картины более подробной, чем в [10]. Никакой стоимости нет.. :(

В plan_table полно колонок, описание которых есть в доках

> В plan_table полно колонок, описание которых есть в доках
>

а то я сам не догадался. спасибо за полезную инфу

SELECT STATEMENT, GOAL = CHOOSE Стоимость=465 Стоимость ЦПУ=233311391 Стомость Вв/Вы=101 Байты=121 Мощность=1 Оптимизатор=CHOOSE Id=0 Операция=SELECT STATEMENT Позиция=465 Id команды=XAU Временная метка=06.06.2007 11:58:21 NESTED LOOPS ANTI Стоимость=465 Стоимость ЦПУ=233311391 Стомость Вв/Вы=101 Байты=121 Мощность=1 Id=1 Операция=NESTED LOOPS Опции=ANTI Id родителя=0 Позиция=1 Id команды=XAU Временная метка=06.06.2007 11:58:21 TABLE ACCESS FULL Имя объекта=ZAYAVKA Стоимость=141 Стоимость ЦПУ=25642415 Стомость Вв/Вы=101 Байты=2948024 Мощность=25414 Оптимизатор=ANALYZED Id=2 Экземпляр объекта=1 Операция=TABLE ACCESS Опции=FULL Id родителя=1 Позиция=1 Id команды=XAU Временная метка=06.06.2007 11:58:21 INDEX RANGE SCAN Имя объекта=PK_ABONENT_ID Стоимость=1 Стоимость ЦПУ=8172 Байты=361930 Мощность=72386 Оптимизатор=ANALYZED Предикаты доступа="ZAYAVKA"."ABONENT_ID"="ABONENT"."ABONENT_ID" Id=3 Тип объекта=UNIQUE Операция=INDEX Опции=RANGE SCAN Id родителя=1 Позиция=2 Колонки поиска=1 Id команды=XAU Временная метка=06.06.2007 11:58:21

Мдя, коряво получилось.
Но зато видно, сколько чего есть. И это не все...

судя по всему надо включить compute statistics для каждой таблицы в запросе, тогда стоимость выводится. Щас буду посмотреть что получилось

Получились следующие результаты:

<< group by - вариант из [7]>>
SELECT STATEMENT, GOAL = CHOOSE Cost=39789199 Cardinality=19 Bytes=41477 IO cost=39789199 SORT GROUP BY Cost=39789199 Cardinality=19 Bytes=41477 IO cost=39789199 NESTED LOOPS Cost=265 Cardinality=179655045 Bytes=392186963235 IO cost=265 HASH JOIN Cost=265 Cardinality=295774 Bytes=345464032 IO cost=265 TABLE ACCESS FULL TOBJECTSTATE Cost=2 Cardinality=82 Bytes=11644 IO cost=2 HASH JOIN Cost=259 Cardinality=3607 Bytes=3700782 IO cost=259 TABLE ACCESS FULL TDICT Cost=2 Cardinality=38 Bytes=570 IO cost=2 TABLE ACCESS FULL TEXPORT Cost=255 Cardinality=3607 Bytes=3646677 IO cost=255 INDEX UNIQUE SCAN TIMPORT_PK Cardinality=607 Bytes=616105
размер набора перед группировкой - просто огромный. Сначала джойним все таблицы, а потом выкидываем в группировке ненужные записи. В принципе было понятно и без костов из самого первого плана :) Непонятно, правда, почему вдруг стало хешированное соединение вместо вложенных циклов

<< sub query - первоначальный вариант>>
SELECT STATEMENT, GOAL = CHOOSE Cost=450684 Cardinality=1 Bytes=2026 IO cost=450684 TABLE ACCESS BY INDEX ROWID TDICT Cost=1 Cardinality=1 Bytes=15 IO cost=1 INDEX UNIQUE SCAN TDICT_PK Cardinality=1 TABLE ACCESS BY INDEX ROWID TOBJECTSTATE Cost=1 Cardinality=1 Bytes=142 IO cost=1 INDEX RANGE SCAN TOBJECTSTATE_PK Cost=1 Cardinality=1 IO cost=1 SORT GROUP BY Cost=450684 Cardinality=1 Bytes=2026 IO cost=450684 NESTED LOOPS Cost=255 Cardinality=2190915 Bytes=4438793790 IO cost=255 TABLE ACCESS FULL TEXPORT Cost=255 Cardinality=3607 Bytes=3646677 IO cost=255 INDEX UNIQUE SCAN TIMPORT_PK Cardinality=607 Bytes=616105
<< select from select >>
SELECT STATEMENT, GOAL = CHOOSE Cost=450686 Cardinality=82 Bytes=16072 IO cost=450686 NESTED LOOPS Cost=450686 Cardinality=82 Bytes=16072 IO cost=450686 NESTED LOOPS Cost=450685 Cardinality=1 Bytes=54 IO cost=450685 VIEW Cost=450684 Cardinality=1 Bytes=39 SORT GROUP BY Cost=450684 Cardinality=1 Bytes=2026 IO cost=450684 NESTED LOOPS Cost=255 Cardinality=2190915 Bytes=4438793790 IO cost=255 TABLE ACCESS FULL TEXPORT Cost=255 Cardinality=3607 Bytes=3646677 IO cost=255 INDEX UNIQUE SCAN TIMPORT_PK Cardinality=607 Bytes=616105 TABLE ACCESS BY INDEX ROWID TDICT Cost=1 Cardinality=1 Bytes=15 IO cost=1 INDEX UNIQUE SCAN TDICT_PK Cardinality=1 TABLE ACCESS BY INDEX ROWID TOBJECTSTATE Cost=1 Cardinality=82 Bytes=11644 IO cost=1 INDEX UNIQUE SCAN TOBJECTSTATE_PK Cardinality=1
здесь отличия от sub query непринципиальные.
Вот как-то так.

Как на оракле будет выглядеть этот запрос Найти похожие ветки