Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
jack128 © (2006-01-18 17:20:00)
День добрый.

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

jack128 (2006-01-19 16:58:00) [1]
Johnmen ©
Я, наивный, специально девятку в примере вставил :-)

Desdechado (2006-01-19 15:26:00) [2]
> для версии FB1.5 соврал
возможно, дело в том, что все мои PK генерировались через GENERATOR последовательно возрастающими и при плане NATURAL создавалясь иллюзия упорядоченности по PK
а сейчас я попробовал просто ручками уникальный разнобой

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

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

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

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

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

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

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

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

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

Johnmen (2006-01-19 13:48:00) [6]
>evvcom © (19.01.06 12:49) [23]
>почему тебя так задело обсуждение связи гарантии сабжа с сортировкой.

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

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

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

Sergey13 (2006-01-19 13:08:00) [7]
Меня Johnmen убедил. В конкретном этом запросе на этом сервере наверное гарантия есть (ну или почти есть 8-). Однако в общем случае могут срабатывать процессы, аналогичные оракловому распаралеливанию выполнения запроса. И тогда гарантии нет.

evvcom (2006-01-19 12:49:00) [8]

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

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

Johnmen (2006-01-19 12:34:00) [9]
>evvcom © (19.01.06 12:26) [21]
>Это к слову о гарантии.

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

evvcom (2006-01-19 12:26:00) [10]

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

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

Johnmen (2006-01-19 12:18:00) [11]
>evvcom © (19.01.06 11:50) [19]

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

evvcom (2006-01-19 11:50:00) [12]

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

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

Desdechado (2006-01-19 11:48:00) [13]
аднака, для версии FB1.5 соврал, ненарочно
видимо изменилось что-то в последней версии
сколько раньше работал (лет 7, наверно), всегда сортировалось

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

Johnmen (2006-01-19 11:33:00) [15]
Не ложь, а заблуждение :)

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

Desdechado (2006-01-19 11:23:00) [17]
>Парадокс (BDE) и Акцес при отсутствии Order By сортируют НД в порядке, определенном перечне полей в запросе.
видимо, все-таки не так
FB, например, при однотабличном запросе с PK или UQ сортирует по нему
это логичное поведение
подозреваю, что парадокс тоже так делает
про акцесс не знаю

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

Johnmen (2006-01-19 11:01:00) [19]
А причём тут вообще сортировка?
Все внимательно прочитали сабж? Похоже, что нет.

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

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

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »