Странное отношение к JOIN

← →
roottim © (2006-10-19 12:47) [40]

with JoinedT2T3 as ( select * from t2, t3 where T3.T2_ID = T2.T2_ID ) select .. from t1, JoinedT2T3 tt where T1.T1_ID = tt.T1_ID(+)

← →
Курдль © (2006-10-19 12:55) [41]

> roottim © (19.10.06 12:47) [40]

Замысловатая игра псевдонимими :)
Но работать будет, на первый взгляд.
Однако, если стараться создавать максимально СУБД-независимый запрос, это уже не проканает...

← →
ANB © (2006-10-19 12:59) [42]

> А как бы это выглядело в нотации оракла (на плюсиках)? Читаемо?

Честно говоря, на плюсиках было бы читаемей. Но оракл 8 не пропустил бы 2 плюсика каскадом.

← →
ANB © (2006-10-19 13:00) [43]

> максимально СУБД-независимый запрос

А оно надо ?
Имхо - такой запрос будет неоптимален на всех серверах. Если только он не select * from table1 t1 where t1.id = :id

← →
roottim © (2006-10-19 13:01) [44]

> максимально СУБД-независимый запрос

Сколько раз убеждался... "Это фантастика..."
ИМНО выбор кросплатформенности и производительности в сторону первого нелогичен, только не все заказщики это понимают.

← →
kaif © (2006-10-19 13:19) [45]

Обычно при разработке я постепенно развиваю запросы от простых к сложным.
При этом если заведомо предполагается, что в запросе не будет фигурировать LEFT OUTER JOIN, о я использую синтаксис с перечислением таблиц и условий связив WHERE.
Мне так проще.
Обычно "доработка" таких запросов сводится к добавлению упущенных связей со справочниками, информацию из которых следовало бы тоже выводить. Удобно такое устройство запросов, если предполагается, что еще будут в ходе разработки добавляться новые поля в таблицы, но смысл объединения останется внутренним.

Однако если предполагается хотя бы одно внешнее объединение (обычно мне это бывает ясно заранее), то предпочитаю тут же начинать с конструкции с INEER JOIN. Так как в такую конструкцию легче потом добавить LEFT OUTER JOIN и не запутаться.

Таким образом я одинаково часто использую и ту и другую конструкцию.
Разумеется я предпочитаю строить базы так, чтобы LEFT OUTER JOIN избежать вообще. Но не всегда это бывает оправдано и даже не всегда возможно.

Думаю оба синтаксиса имеют свое законное право на существование.
Я бы не рискнул утверждать, что какой-то из них предпочтительнее.

Так как синтаксис с перечислением таблиц и условиями в WHERE позволяет не ошибиться с алиасами таблиц, так как все сразу видно (я пишу таблицы в столбик). Замечал, что в конструкциях с JOIN-ами я часто при добавлении новой связи копирую через буфер обмена предыдущее условие и иногда по невнимательности забываю везде усказать новый алиас (если таблица с тем же именем), что иногда чревато весьма, вплоть до случайного запроса декартовых произведений (согласитесь это очень неприятно, если просто забыл изменить T2.ID на T3.ID где-то в условии)

← →
evvcom © (2006-10-19 14:23) [46]

> [45] kaif © (19.10.06 13:19)
> Так как синтаксис с перечислением таблиц и условиями в WHERE
> позволяет не ошибиться с алиасами таблиц

Весьма спорное утверждение. Видимо, опять дело привычки.

> Замечал, что в конструкциях с JOIN-ами я часто при добавлении
> новой связи копирую через буфер обмена предыдущее условие

Я не копирую. inner join набрать недолго, а после алиаса и точки PL/SQL Developer вываливает список возможных полей. Остается только выбрать нужное.

← →
Курдль © (2006-10-19 15:02) [47]

> roottim © (19.10.06 13:01) [44]
> Сколько раз убеждался... "Это фантастика..."
> ИМНО выбор кросплатформенности и производительности в сторону
> первого нелогичен, только не все заказщики это понимают.

Приведите мне пример разных запросов, выбирающих один и тот же набор данных, для разных СУБД (напр. МССКЛ и оракла), чтобы они использовали какие-то особенные способы повышения производительности (хинты не в счет - их можно и по вкусу добавить). Желательно со схемами запросов.

← →
roottim © (2006-10-19 16:56) [48]

> Приведите мне пример

Да дело здесь не столько в запросах, сколько в реализации в целом..
К сожалению большого опыта общения с MSSQL нет

Но могу например указать на кластериизацию таблиц, partition table, использование bitmap index..
Удобно использовать rowid

Ну и хинты вы зря отбросили..
например как Сделать
select --+ INDEX_DESC(t idx_t) t.value from table1 t where t.buh_date < :p_date and rownum = 1
который выдаст мне актульный срез на дату

т.е. в угоду совместимости вы жертвуйте фичами и соотв-но производительностью

← →
AlexWlad © (2006-10-19 19:40) [49]

Наблюдение: те, кто против джойнов - явно пишут запросы "ручками".
Лично я давно на это "забил". Все связи между таблицами только визуально в Студии.
Более того, SQL2000 принимая запрос со связями вида "*=" (стиль 6.5) и т.п., сначала превращает их в джойны, и только потом - на выполнение.

← →
Petr V.Abramov (2006-10-19 20:13) [50]

← →
Sergey Masloff (2006-10-19 20:20) [51]

Курдль © (19.10.06 15:02) [47]
Да например выбрать все документы где куратор из (дерево подразделений) но не в (поддерево подразделений)
connect by оракловский настолько быстрее работает чем альтернативные методы...

Для средних по объему продуктов, вроде всегда можно такие уникальные запросы оформить хранимками. Или я не прав?

← →
Sergey Masloff (2006-10-19 21:12) [53]

atruhin © (19.10.06 20:54) [52]
>Для средних по объему продуктов, вроде всегда можно такие уникальные >запросы оформить хранимками. Или я не прав?
Я приводил статистику. У нас 30 тыс уникальных запросов в день. Не по параметрам а по составу. Из них большая часть "деревянные" (иерархические).
Просто если бы писать это под MS SQL например предпочтительнее было просто схему данных по-другому проектировать. Для оракла эффективно оказалось именно так.

Странное отношение к JOIN Найти похожие ветки