Форум: "Базы";
Текущий архив: 2006.03.12;
Скачать: [xml.tar.bz2];
Внизособенности работы 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]
Это к слову о гарантии. Мое мнение, что гарантии никакой. Вот к тому и сортировка. Если быть уверенным, что сервер будет перебирать отсортированные значения, то еще можно говорить о каких-то гарантиях, а так нет.
← →
Johnmen © (2006-01-19 12:34) [22]>evvcom © (19.01.06 12:26) [21]
>Это к слову о гарантии.
О гарантии чего?
Того, что в сабже, или того, что все здесь обсуждают?
← →
evvcom © (2006-01-19 12:49) [23]
> О гарантии чего?
Я перечитал и [12], и сабж. О гарантии сабжа.
Если честно, что-то я не понял, почему тебя так задело обсуждение связи гарантии сабжа с сортировкой. Почему ты считаешь, что они не связаны?
← →
Sergey13 © (2006-01-19 13:08) [24]Меня Johnmen убедил. В конкретном этом запросе на этом сервере наверное гарантия есть (ну или почти есть 8-). Однако в общем случае могут срабатывать процессы, аналогичные оракловому распаралеливанию выполнения запроса. И тогда гарантии нет.
← →
Johnmen © (2006-01-19 13:48) [25]>evvcom © (19.01.06 12:49) [23]
>почему тебя так задело обсуждение связи гарантии сабжа с сортировкой.
Да не задело. Просто несколько удивительно, что почти все не видят, что гарантия в сабже к сортировке имеет весьма опосредованное отношение.
>Sergey13 © (19.01.06 13:08) [24]
Я же ведь тоже не с потолка это взял :)
Но много читал про базовые принципы функционирования сервера (IB). В частности, про методику выполнения селективных запросов. Которая, кстати, построена на общих принципах ф-ия серверов...
Где читал, не скажу, давно это было, да и ресурсов этих в инете уже нет.
М.б. есть другие, где это освещается. Не знаю.
← →
Fay © (2006-01-19 14:05) [26]2 Johnmen © (19.01.06 13:48) [25]
Гарантию порядка записей даёт только order by, а сабж имеет к ней (гарантии) "весьма опосредованное отношение".
З.Ы.
Понятия "почти" и "гарантиия" не совместимы.
← →
Johnmen © (2006-01-19 14:14) [27]>Fay © (19.01.06 14:05) [26]
>Понятия "почти" и "гарантиия" не совместимы.
А где я совмещал?
>Гарантию порядка записей даёт только order by,
В данном контексте, данный сабжевый порядок, не только он!
← →
Fay © (2006-01-19 15:09) [28]2 Desdechado © (19.01.06 11:48) [18]
> аднака, для версии FB1.5 соврал
И для 1.0.3.972 тоже. А в какой нужно проверять?
2 Johnmen © (19.01.06 14:14) [27]
Проверяю.
← →
Desdechado © (2006-01-19 15:26) [29]> для версии FB1.5 соврал
возможно, дело в том, что все мои PK генерировались через GENERATOR последовательно возрастающими и при плане NATURAL создавалясь иллюзия упорядоченности по PK
а сейчас я попробовал просто ручками уникальный разнобой
в Оракле же даже с такой генерацией PK порядок весьма произвольный
← →
jack128 © (2006-01-19 16:58) [30]Johnmen ©
Я, наивный, специально девятку в примере вставил :-)
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2006.03.12;
Скачать: [xml.tar.bz2];
Память: 0.52 MB
Время: 0.013 c