Странное отношение к 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]
> Вот бы кто-то стал переписывать ;-))
озвучьте цену вопроса :))))

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] никуда не девается

> [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 :-), и сиди лови ошибки. "Красота", блин!

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

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

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

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

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

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

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

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

скорее всего хотели на 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(+)

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