В чём ейная экстраординарная вредность?CyberMax писал(а):Есть такая вещь, как неявный джойн. Она существует как наследие SQL-89. Тем не менее, это не полезная, это вредная вещь.
Кстати, WildSery был практически прав. Хотя, возможно, сейчас ситуация выглядит уже другим образом. Если это так, пусть разработчики поправят.Неявное соединение поддерживается в Firebird для совместимости с кодом существующих приложений. [...] Можно предположить, что в будущем стандарте этот синтаксис будет отсутствовать.
искоренять неявный джойн никто не будет, в здравом уме.Хотя, возможно, сейчас ситуация выглядит уже другим образом. Если это так, пусть разработчики поправят.
Хоть книжка ета (в оригинале, ессно) у меня лежит на полке с автографом, должен сказать, что это дааалеко не единственный пункт, где мы расходимся во мнениях. Ну и, ессно, там где мы таки в них расходимся, всегда прав я 
Не аргумент ваще. Если даже настолько лень, всегда есть вариант WHERE 1=1Merlin писал(а):в смысле присобачивания к ним разных условий фильтрации - в нём всегда уже есть WHERE и можно не думая приляпывать очередной AND.
Тут не догнал. Можно пример, чего "парсер не сожрёт"?Merlin писал(а):...мы просто обязаны писать её и её условия соединения последними, иначе парсер просто не сожрёт.
И наоборот, при неявном соединении, оптимизатор будет в точности выполнять всё что задумал автор, так что ли понимать сей аргумент?Merlin писал(а):При этом не факт что оптимальная последовательность пересечений множеств будет соответствовать записи. И совсем не факт, что оптимизатор вообще будет ей следовать.
select first 1 skip 100000 * from sebg_arcWildSery писал(а):Не аргумент ваще. Если даже настолько лень, всегда есть вариант WHERE 1=1Merlin писал(а):в смысле присобачивания к ним разных условий фильтрации - в нём всегда уже есть WHERE и можно не думая приляпывать очередной AND.
Реальные запросы, на которых спотыкался и искать лень и места до фига займут. Примитивный экзампл:WildSery писал(а):Тут не догнал. Можно пример, чего "парсер не сожрёт"?Merlin писал(а):...мы просто обязаны писать её и её условия соединения последними, иначе парсер просто не сожрёт.
Код: Выделить всё
ежель их все в явные переписывать... select T.*
from T T1
join T T2 on T2.ID=T1.ID and T2.ID=T3.ID
join T T3 on T3.ID=T1.ID
Нет, это надо понимать как то, что наглядность явного обманчива и на самом деле никаких преимуществ перед неявным не даёт.WildSery писал(а):И наоборот, при неявном соединении, оптимизатор будет в точности выполнять всё что задумал автор, так что ли понимать сей аргумент?Merlin писал(а):При этом не факт что оптимальная последовательность пересечений множеств будет соответствовать записи. И совсем не факт, что оптимизатор вообще будет ей следовать.
Начну издалека: все старое - более "дубовое" по сравнению с новым. Взять любую область - программы, техника, дома и т.д. - это правило работает. Но без этого никак - потому что это и есть эволюция.kdv писал(а):кроме того, использование только неявных или наоборот, только явных джойнов граничит с ортодоксальностью, причем бессмысленой.
), то я буду в первых рядах адептов нового типа джойна .
Мне неизвестны. Кстати, прям сегодня на FB1.5.3 наступил на случай, когда в явном inner джойне опять получался совершенно разный план в зависимости от того, в where или в on размещено одно из условий. Переписывать на неявный и сверять было влом, непростой денёк выдался. Я не пытаюсь сказать что явный хуже или лучще, я пытаюсь донести что они равноправны. Есть нюансы, которые надо учитывать при пользовании тем и другим и всё. Вот если имеем цепочку inner соединений, на конце которой привешен left (а тут ясен перец весь запрос должен быть явным) то на 1.5.х частенько получается она, белая, круглая, полная, одним словом - жопа. Последовательность объединений не рулится секцией Plan и на тех же индексах запрос, который может выполняться за десятки мсек, идёт сотниWildSery писал(а):2 Merlin:
Кроме случаев "парсер не сожрёт" (невозможно переделать в явный только при условии использования трёх условий по каждому из трёх алиасов), есть ещё какие-нибудь ситуации, когда явный join уступает неявному?
Неверная посылка. Тут дело не в старом и новом. Можно сказать - да ну его нах, не пойду с сегодня вотку пить, а можно - не поёду я сегодня вотку пить, н уего нах. Вот и вся разница.CyberMax писал(а): Начну издалека: все старое - более "дубовое" по сравнению с новым.
Отмечаем с опозданием на неделю мою днюху на работе .На глаз не припоминаю, чтобы не получилось добиться хорошего плана. Наверное, у тебя запросы посложнее? Или такие бяки строю отдельно в ХП, как вложенный.Merlin писал(а):Последовательность объединений не рулится секцией Plan и на тех же индексах запрос, который может выполняться за десятки мсек, идёт сотни