особенности работы left join

← →
jack128 © (2006-01-18 17:20) [0]

День добрый.

FB1.5

есть запрос
select t1.id as t1_id, t2.id as t2_id from table1 left join table2 t2 on t1.id = t2.t1_id -- обычная связь по внешнему ключу.

одной записи в table1 может соответствовать несколько записей в table2
скажите есть ли ГАРАНТИЯ, что в результате записи с одинаковым table1.id будут идти подряд:

t1_id t2_id 1 1 1 2 // сначала все записи с t1_id = 1 1 3 9 30 // потом например t1_id = 9 9 40 2 4 2 6 3 7 4 45 4 78

← →
Sergey13 © (2006-01-18 17:23) [1]

Нет. Порядок записей гарантируется только сортировкой.

← →
Курдль © (2006-01-18 17:23) [2]

> что в результате записи с одинаковым table1.id будут идти
> подряд:

Никакая СУБД не дает никакой гарантии о порядке записей, возвращенных запросом, если в нем не содержится ... order by ... :-)

← →
jack128 © (2006-01-18 17:27) [3]

Ну сортировка, так сортировка.
Спасибо.

← →
Sergey13 © (2006-01-18 17:28) [4]

2[2] Курдль © (18.01.06 17:23)
Вроде еще Group By вызывает неявную сортировку.

← →
jack128 © (2006-01-18 17:40) [5]

Sergey13 © (18.01.06 17:28) [4]
гм. Уточню, меня не интересует неявные вещи, которые могут измениться в будущих версиях сервера. Только гарантированные сортировки!

← →
Johnmen © (2006-01-18 17:41) [6]

А я так думаю, причем почти уверен, что гарантия есть.

← →
Johnmen © (2006-01-18 17:45) [7]

Поясню.
При таком соединении сначала выполняется обход "внешней" таблицы, в нашем случае Table1. И для каждой записи ищется соответствующие в Table2.
Поскольку Table1.ID уникален и обход "внешней" делается 1 раз, то это и гарантирует сабж.

← →
DSKalugin © (2006-01-18 18:34) [8]

> select t1.id as t1_id, t2.id as t2_id
> from table1
> left join table2 t2 on t1.id = t2.t1_id -- обычная связь
> по внешнему ключу.

по поводу t2.t1_id а t1_id вообще есть у table2 или же
t1_id это t1.id судя по select t1.id as t1_id
?

← →
jack128 © (2006-01-19 10:50) [9]

DSKalugin © (18.01.06 18:34) [8]
по поводу t2.t1_id а t1_id вообще есть у table2
есть естественно. в запросе четко написано on t1.id = t2.t1_id
DSKalugin © (18.01.06 18:34) [8]
t1_id это t1.id судя по select t1.id as t1_id
а какое имеет значение, что за псевдонимы я полям присвоил??
Johnmen © (18.01.06 17:45) [7]
Ну вот мне тоже так показалось, потому я и решил уточнить.

← →
Fay © (2006-01-19 10:56) [10]

2 jack128 © (19.01.06 10:50) [9]
Гарантию даёт только order by. Остальное - ересь.

← →
msguns © (2006-01-19 10:57) [11]

>Курдль © (18.01.06 17:23) [2]
>Никакая СУБД не дает никакой гарантии о порядке записей, возвращенных запросом, если в нем не содержится ... order by ... :-)

Парадокс (BDE) и Акцес при отсутствии Order By сортируют НД в порядке, определенном перечне полей в запросе.

С IB работал не так много, но мне показалось, что ситуация похожая.

Вообще же рекомендуется ВСЕГДА задавать порядок явно, если в вых.НД в этом есть необходимость.

← →
Johnmen © (2006-01-19 11:01) [12]

А причём тут вообще сортировка?
Все внимательно прочитали сабж? Похоже, что нет.

← →
Sergey13 © (2006-01-19 11:04) [13]

2[11] msguns © (19.01.06 10:57)
>Парадокс (BDE) и Акцес при отсутствии Order By сортируют НД в порядке, определенном перечне полей в запросе.
Это правда? Тогда запрос типа select * from table из миллионной таблицы должен вызывать просто-таки сумашедшую сортировку. Что-то мне сомнительно это.

← →
Desdechado © (2006-01-19 11:23) [14]

>Парадокс (BDE) и Акцес при отсутствии Order By сортируют НД в порядке, определенном перечне полей в запросе.
видимо, все-таки не так
FB, например, при однотабличном запросе с PK или UQ сортирует по нему
это логичное поведение
подозреваю, что парадокс тоже так делает
про акцесс не знаю

← →
Fay © (2006-01-19 11:32) [15]

2 Desdechado © (19.01.06 11:23) [14]
> FB, например, при однотабличном запросе с PK или UQ сортирует по нему
Ложь.

← →
Johnmen © (2006-01-19 11:33) [16]

Не ложь, а заблуждение :)

← →
Fay © (2006-01-19 11:37) [17]

2 Johnmen © (19.01.06 11:33) [16]
Я имел ввиду результат проверки истинности утверждения 8)

← →
Desdechado © (2006-01-19 11:48) [18]

аднака, для версии FB1.5 соврал, ненарочно
видимо изменилось что-то в последней версии
сколько раньше работал (лет 7, наверно), всегда сортировалось

← →
evvcom © (2006-01-19 11:50) [19]

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

Не знаю как в FB, но в оракле есть 3 основных типа джойнов: Nested Loops Join, Merge Join и Hash Join. Только для Merge Join выполняется предварительная сортировка. А для остальных сортировка будет присутствовать, только если выборка пойдет по нужному индексу.

← →
Johnmen © (2006-01-19 12:18) [20]

>evvcom © (19.01.06 11:50) [19]

Ну божешь ты мой... см.[12]

← →
evvcom © (2006-01-19 12:26) [21]

> Johnmen © (19.01.06 12:18) [20]

Это к слову о гарантии. Мое мнение, что гарантии никакой. Вот к тому и сортировка. Если быть уверенным, что сервер будет перебирать отсортированные значения, то еще можно говорить о каких-то гарантиях, а так нет.

>evvcom © (19.01.06 12:26) [21]
>Это к слову о гарантии.

О гарантии чего?
Того, что в сабже, или того, что все здесь обсуждают?

> О гарантии чего?

Я перечитал и [12], и сабж. О гарантии сабжа.
Если честно, что-то я не понял, почему тебя так задело обсуждение связи гарантии сабжа с сортировкой. Почему ты считаешь, что они не связаны?

Меня Johnmen убедил. В конкретном этом запросе на этом сервере наверное гарантия есть (ну или почти есть 8-). Однако в общем случае могут срабатывать процессы, аналогичные оракловому распаралеливанию выполнения запроса. И тогда гарантии нет.

>evvcom © (19.01.06 12:49) [23]
>почему тебя так задело обсуждение связи гарантии сабжа с сортировкой.

Да не задело. Просто несколько удивительно, что почти все не видят, что гарантия в сабже к сортировке имеет весьма опосредованное отношение.

>Sergey13 © (19.01.06 13:08) [24]

Я же ведь тоже не с потолка это взял :)
Но много читал про базовые принципы функционирования сервера (IB). В частности, про методику выполнения селективных запросов. Которая, кстати, построена на общих принципах ф-ия серверов...
Где читал, не скажу, давно это было, да и ресурсов этих в инете уже нет.
М.б. есть другие, где это освещается. Не знаю.

2 Johnmen © (19.01.06 13:48) [25]
Гарантию порядка записей даёт только order by, а сабж имеет к ней (гарантии) "весьма опосредованное отношение".

З.Ы.
Понятия "почти" и "гарантиия" не совместимы.

>Fay © (19.01.06 14:05) [26]
>Понятия "почти" и "гарантиия" не совместимы.

А где я совмещал?

>Гарантию порядка записей даёт только order by,

В данном контексте, данный сабжевый порядок, не только он!

2 Desdechado © (19.01.06 11:48) [18]
> аднака, для версии FB1.5 соврал
И для 1.0.3.972 тоже. А в какой нужно проверять?

2 Johnmen © (19.01.06 14:14) [27]
Проверяю.

> для версии FB1.5 соврал
возможно, дело в том, что все мои PK генерировались через GENERATOR последовательно возрастающими и при плане NATURAL создавалясь иллюзия упорядоченности по PK
а сейчас я попробовал просто ручками уникальный разнобой

в Оракле же даже с такой генерацией PK порядок весьма произвольный

особенности работы left join Найти похожие ветки