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

← →
Александр Иванов © (2006-10-18 18:28) [0]

Участвовал однажды в проекте. Кроме всего прочего написал порядка 30 запросов, причем некоторые сложные. Недавно полез в исходники - из всех запросов "выгрызли" JOIN. Т.е. запросы не переписаны, только JOIN"ы перенесыны во FROM и WHERE.
Это новая инструкция ВЦСПС, которую я пропустил? :)

← →
k2 © (2006-10-18 18:29) [1]

вернуться к корням наверное захотелось :)

← →
Александр Иванов © (2006-10-18 18:32) [2]

> k2 © (18.10.06 18:29) [1]

К корням чего только? Не помню, чтобы в SQL JOIN"ов не было.

← →
k2 © (2006-10-18 18:33) [3]

Александр Иванов © (18.10.06 18:32) [2]
в оракле например синтаксис был (+)

← →
Александр Иванов © (2006-10-18 18:38) [4]

> k2 © (18.10.06 18:33) [3]

Но это дополнительные возможности. Там же тоже есть JOIN.

← →
Jeer © (2006-10-18 18:42) [5]

Александр Иванов © (18.10.06 18:28)

"Разные серваки по разному реагируют на, казалось бы, простые запросы."

← →
Плохиш © (2006-10-18 19:04) [6]

> Александр Иванов © (18.10.06 18:28)

> Это новая инструкция ВЦСПС, которую я пропустил?

Ты, всерьёз, считаешь, что здесь тусуются специалисты по политическому устройству Узбекистана?

← →
Александр Иванов © (2006-10-18 19:05) [7]

> Jeer © (18.10.06 18:42) [5]

Сервер Oracle 10g. Я не слышал, что он неадекватно реагирует на JOIN.

← →
Александр Иванов © (2006-10-18 19:07) [8]

> Плохиш © (18.10.06 19:04) [6]

http://www.rubricon.com/mosenc_9_2.asp
ВЦСПС Всероссийский Центральный Совет профсоюзов
Это анекдот был такой...

← →
Курдль © (2006-10-18 19:10) [9]

> Jeer © (18.10.06 18:42) [5]
> "Разные серваки по разному реагируют на, казалось бы, простые запросы."

На ANSI SQL все серваки должны реагировать одинаково! Те серваки, которые реагируют иначе - в топку!
Другое дело, что некоторые СУБД допускают join без on, если предполагается использование внешних ключей. Но вот такое программирование уже опасно.

← →
ораклоид (2006-10-18 19:14) [10]

> На ANSI SQL все серваки должны реагировать одинаково

Так, в качестве любопытства: а есть какой-нибудь сервер, 100%-но соответствующий стандартам ANSI SQL?

← →
ИА (2006-10-18 19:47) [11]

> Участвовал однажды в проекте. Кроме всего прочего написал
> порядка 30 запросов, причем некоторые сложные. Недавно полез
> в исходники - из всех запросов "выгрызли" JOIN. Т.е. запросы
> не переписаны, только JOIN"ы перенесыны во FROM и WHERE.
>
> Это новая инструкция ВЦСПС, которую я пропустил? :)

Просто стиль. Я к примеру тоже не люблю писать Join, мне удобнее From & Where, особенно на больших запросах легче читать по блокам, сначала из чего выбираем, потом критерии. Специально конечно менять бы не стал - не трогай то что и так работает, а за пустые изменения бить по шаловливым пальчикам.

← →
kaif © (2006-10-18 20:25) [12]

Как версия: может быть какие-то оптимизаторы по-разному планируют запросы с WHERE и сплошными INNER JOIN ?

← →
Desdechado © (2006-10-18 20:37) [13]

Оракл, кстати, немного по-разному реагирует на (+) и JOIN
Читал в его доках, что на старый синтаксис оптимизатор не заточен, поэтому рекомендуют JOIN

← →
Sergey Masloff (2006-10-18 21:23) [14]

Desdechado © (18.10.06 20:37) [13]
Приведи ссылку ;-) Вроде неправда все это
И при чем здесь синтаксис оптимизатор с деревом разбора работает а оно при любом синтаксисе одинаковое будет

← →
Карелин Артем © (2006-10-18 21:28) [15]

По легендам, в IB были проблемы с джойнами.

← →
Sergey Masloff (2006-10-18 21:37) [16]

Карелин Артем © (18.10.06 21:28) [15]
>По легендам, в IB были проблемы с джойнами.
Да не легенды даже... было дело но некритично. Но тут оракл ;-)

← →
Petr V.Abramov (2006-10-18 22:31) [17]

> Т.е. запросы не переписаны, только JOIN"ы перенесыны во FROM и WHERE.
> причем некоторые сложные.
буков меньше, читать быстрее. ИМХО, достаточно веская причина

← →
Zacho © (2006-10-18 22:38) [18]

Petr V.Abramov (18.10.06 22:31) [17]

Ну, это кому как. Мне, например, гораздо быстрее и проще разобраться в запросе с явным JOIN. Сразу видно условия соедининия конкретной таблицы и условия соединения не путаются с условиями, ограничивающими выборку.

← →
Kerk © (2006-10-18 22:45) [19]

Никогда не использую JOIN. Не люблю.

← →
Zacho © (2006-10-18 22:48) [20]

Kerk © (18.10.06 22:45) [19]

Даже внешние ?
:)

← →
Kerk © (2006-10-18 22:49) [21]

> [20] Zacho © (18.10.06 22:48)

Никакие :)
Я (+) использую

← →
Германн © (2006-10-18 22:56) [22]

> Kerk © (18.10.06 22:45) [19]
>
> Никогда не использую JOIN. Не люблю.
>

Несколько лет назад мне не удалось написАть некий запрос без JOIN. Так что люблю, не люблю, а "плюнуть" не получается. :-)

← →
Sergey Masloff (2006-10-18 23:00) [23]

Kerk © (18.10.06 22:49) [21]
>Я (+) использую
То бишь открытые. От того что ключевое слово join не написано джойн джойном быть не перестает

← →
Petr V.Abramov (2006-10-18 23:25) [24]

> Мне, например, гораздо быстрее и проще разобраться в запросе с явным JOIN
select что-то from (t1 inner join t2 on t1.id=t2.id) inner join t3 on t3.id=t2.id where t1.id=1

select что-то from t1, t2,t3 where t1.id = t2.id and t3.id = t2.id and t1.id = 1

сначала мухи (какие таблицы вообще трогаются) потм котлеты (а зачем и как )

← →
Petr V.Abramov (2006-10-18 23:27) [25]

форматирование в [24] поплыло, но это на принцип не влияет :)

← →
Sergey Masloff (2006-10-18 23:31) [26]

По поводу же сабжа - да все равно как писать лишь бы одинаково везде. Так что если система развивается а новая команда пишет всегда через плюсики то вполне логично переписать и старое. Тем более что их там 30 штук всего.
Вот я статистику за день тут смотрел - 30 тыс. уникальных запросов. Естественно все параметризованные и имеется в виду 30 тыс уникальных текстов параметризованных запросов. Вот бы кто-то стал переписывать ;-))

← →
Zacho © (2006-10-18 23:33) [27]

Petr V.Abramov (18.10.06 23:25) [24]

Ну ясно, что от форматирования текста сильно зависит его читабельность, но именно мне приятнее явный JOIN. :)
Да и ошибку сделать с явным JOIN несколько сложнее, чем с неявным.
Впрочем, никого убеждать я не собираюсь, да и не считаю, что есть большая разница в использовании явных и неявных JOIN.

← →
Petr V.Abramov (2006-10-18 23:42) [28]

> Zacho © (18.10.06 23:33) [27]
> Да и ошибку сделать с явным JOIN несколько сложнее, чем с неявным.
в чем сложность? и в чем простота отлавливания?

> Sergey Masloff (18.10.06 23:31) [26]
> Вот бы кто-то стал переписывать ;-))
озвучьте цену вопроса :))))

← →
Zacho © (2006-10-18 23:50) [29]

Petr V.Abramov (18.10.06 23:42) [28]
в чем сложность?

OR вместо AND между условиями соединения разных таблиц ну никак написать не получится :)

Впрочем, мелочи это. Просто мне явный Join привычнее, кому-то неявный привычнее..

← →
Petr V.Abramov (2006-10-19 00:04) [30]

> Zacho © (18.10.06 23:50) [29]
> Просто мне явный Join привычнее, кому-то неявный привычнее..
согласен. но [17] никуда не девается

← →
evvcom © (2006-10-19 09:02) [31]

> [11] ИА (18.10.06 19:47)
> мне удобнее From & Where, особенно на больших запросах легче
> читать по блокам, сначала из чего выбираем, потом критерии

Имхо, конструкция JOIN ... ON более наглядна. Сразу за таблицей следует условие связи. В случае с from where условия все в куче. Не вижу наглядности. Но это мое имхо.

> [21] Kerk © (18.10.06 22:49)

Напиши full join с плюсами :)

> [27] Zacho © (18.10.06 23:33)
> Да и ошибку сделать с явным JOIN несколько сложнее, чем
> с неявным

Эт точно (с) Сухов
забыл в where условие связки написать и получил cross join вместо inner/outer join :-), и сиди лови ошибки. "Красота", блин!

← →
Александр Иванов © (2006-10-19 09:16) [32]

> По легендам, в IB были проблемы с джойнами.

Скорее это все объясняет. Человек до этого работал только с IB/FB.

← →
Zacho © (2006-10-19 09:21) [33]

Александр Иванов © (19.10.06 9:16) [32]

Возможно, но "проблемы с джойнами" в IB были весьма давно, если мне память не изменяет до версии 5.0, а это 1998 г.

← →
Bless © (2006-10-19 09:42) [34]

> evvcom © (19.10.06 09:02) [31]
>
> Имхо, конструкция JOIN ... ON более наглядна. Сразу за таблицей
> следует условие связи. В случае с from where условия все
> в куче. Не вижу наглядности. Но это мое имхо.

Согласен. Условие связи после ON нечаянно не пропустишь, заругается. И если стоит, то так и хотел автор запроса. А с where сиди потом догадывайся, это так специально было задумано, что условие связи не стоит, или это и есть та ошибка, котурую я ищу :)

← →
Vlad433 © (2006-10-19 09:47) [35]

ИМХО, в IB joinы оптимизируются лучше, чем where. Как в оракле, не знаю. Читабельность - дело привычки...

← →
Игорь Шевченко © (2006-10-19 10:24) [36]

Присоединяюсь к [24].
Лучше писать проще.

← →
ANB © (2006-10-19 11:17) [37]

скорее всего хотели на 8-ку откатится. Она не есть явные джойны. А потом передумали :)

Sergey Masloff (18.10.06 21:23) [14]
> Desdechado © (18.10.06 20:37) [13] Приведи ссылку ;-)
> Вроде неправда все это
Выдержка из SQL Reference для 9.2
Oracle Corporation recommends that you use the FROM clause OUTER JOIN syntax rather than the Oracle join operator. Outer join queries that use the Oracle join operator (+) are subject to the following rules and restrictions, which do not apply to the FROM clause join syntax: n You cannot specify the (+) operator in a query block that also contains FROM clause join syntax. n The (+) operator can appear only in the WHERE clause or, in the context of left-correlation (that is, when specifying the TABLE clause) in the FROM clause, and can be applied only to a column of a table or view. n If A and B are joined by multiple join conditions, then you must use the (+) operator in all of these conditions. If you do not, then Oracle will return only the rows resulting from a simple join, but without a warning or error to advise you that you do not have the results of an outer join. n The (+) operator does not produce an outer join if you specify one table in the outer query and the other table in an inner query. n You cannot use the (+) operator to outer-join a table to itself, although self joins are valid. For example, the following statement is not valid: -- The following statement is not valid: SELECT employee_id, manager_id FROM employees WHERE employees.manager_id(+) = employees.employee_id; However, the following self join is valid: SELECT e1.employee_id, e1.manager_id, e2.employee_id FROM employees e1, employees e2 WHERE e1.manager_id(+) = e2.employee_id; n The (+) operator can be applied only to a column, not to an arbitrary expression. However, an arbitrary expression can contain one or more columns marked with the (+) operator. n A condition containing the (+) operator cannot be combined with another condition using the OR logical operator. n A condition cannot use the IN comparison condition to compare a column marked with the (+) operator with an expression. n A condition cannot compare any column marked with the (+) operator with a subquery. If the WHERE clause contains a condition that compares a column from table B with a constant, then the (+) operator must be applied to the column so that Oracle returns the rows from table A for which it has generated nulls for this column. Otherwise Oracle will return only the results of a simple join. In a query that performs outer joins of more than two pairs of tables, a single table can be the null-generated table for only one other table. For this reason, you cannot apply the (+) operator to columns of B in the join condition for A and B and the join condition for B and C.

Как-то мне пришлось портировать запросы с одной базы на оракл.
Это было ожидаемо, т.к. программа писалась с прицелом на возможную смену СУБД по желанию заказчика. Поэтому старались придерживаться строгих запросов. Но некоторые приводили к затруднениям. Например этот:
...from T1 left outer join (T2, T3) on T3.T2_ID = T2.T2_ID and T2.T1_ID = T1.T1_ID

удалось это перевести на:

T1 left outer join (T2 inner join T3 on T3.T2_ID = T2.T2_ID) on T2.T1_ID = T1.T1_ID

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

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(+)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да дело здесь не столько в запросах, сколько в реализации в целом..
К сожалению большого опыта общения с 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
который выдаст мне актульный срез на дату

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

Наблюдение: те, кто против джойнов - явно пишут запросы "ручками".
Лично я давно на это "забил". Все связи между таблицами только визуально в Студии.
Более того, 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 Найти похожие ветки