ChAОригинальный подход к сравнению синтаксиса.
Вот поэтому я не люблю беседовать на флеймовые темы с несколькими людьми одновременно. Обязательно рано или поздно кто-нибудь выхватит фразу из контекста.

Локшин МаркНо что касается внешних соединений, то ответ на вопрос по-моему уже давно содержится в BOL к MS SQL
Еще во время прошлого обсуждения этого вопроса было показано, что убогая реализация *= в MSSQL никоим образом не является аргументом при обсуждении чего-либо кроме MSSQL. Повторять двадцать страниц того топика, честно говоря, не хочется; пожалуйста воспользуйтесь поиском (это было в "Сравнение СУБД", название топика к сожалению не помню).

Локшин МаркЕсли Вы про это
Нет, не про это. Вроде как обсуждение было не так давно; беседовали мы в основном с pkarklin , и в итоге он не смог привести примера, который я бы не смог корректно реализовать с использованием (+)

Локшин МаркИ скобками в where делу не поможешь
А кто говорит про скобки в where? :))

Локшин Марк

Локшин Марк
Кстати, отмечу, что в случае Oracle здесь никакой неоднозначности не будет - будет ошибка. Что пожалуй правильнее.

Локшин МаркНу так и в MS SQL тоже будет на этот запрос:
А к чему тогда относится ранее процитированная фраза насчет возможности неоднозначной интерпретации?

Локшин МаркПо поводу вашего варианта. Запросы то эквивалентные,
Я бы особо отметил, что не просто запросы эквивалентные, но и их алгебраическая запись одинакова.

Локшин Маркно это извините не только соединение в условии фильтрации, а соединение в условии фильтрации + еще и подзапрос с соединением в условии фильтрации. Что как-бы вещи IMHO немного разные.
Чем именно? Ваши скобки в join-е - это ровно такой же подзапрос, просто неявно оформленный.

Локшин МаркЯ не говорю, про чисто субъективную вещь как это будет смотреться при 5-6 последовательных outer join' ах.
И все неоднозначные? Не уверен, что хоть раз в жизни встречал такой запрос :)

Я бы хотел сразу определить обсуждаемое утверждение. Если мы говорим о "лучшем варианте синтаксиса в той или иной ситуации", я согласен с тем, что в некоторых ситуациях join-синтаксис предпочтительнее. Если мы сравниваем синтаксисы, так или иначе говорим о "лучше было бы везде использовать единый синтаксис, и это должен быть такой-то", то повторю - любой аргумент вида "лучше в 1% случаев" должен быть очень весок, чтобы перебороть "хуже во всех оставшихся случаях".

Локшин МаркНо от таких вот выкрутасов оптимизатор у вас в какой-нибудь раз забудет об индексе/статистике
Хм. Обещаете?

Вот тут я сошлюсь на сказанное выше - у этих запросов одинаковая алгебраическая запись. Если бы мои программисты принесли мне оптимизатор, способный построить для них разные планы - я бы послал их.... переделывать работу с начала. Потому что это означает принципиально некорректное проектирование оптимизатора.

Простите, но даже думать об этом варианте не вижу смысла. Впрочем, заодно для полноты картины могу подкинуть контрпример, относящийся как раз к попытке исправить "неправильное поведение оптимизатора". В where-синтаксисе возможно написать так:


Было бы интересно посмотреть на аналогичную запись в случае ansi join-ов.

Локшин МаркЗачем усложнять жизнь и себе и оптимизатору?
Ну в общем-то см. выше.

Локшин Марк softwarerА к чему тогда относится ранее процитированная фраза насчет возможности неоднозначной интерпретации?
Ну такая запись дает возможность неоднозначной трактовки запроса, что тут не понятного.
Трактовки кем? Сервером? Так вроде бы согласно последней версии сказанного Вами он трактует такой запрос однозначно и правильно - как ошибочный. Трактовки программистом? Хм, какая собственно разница, как именно он трактует ошибочный запрос? Кем еще?

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

Локшин МаркВсем изместно, что система опраторов реляционной алгебры не минимальна, и одни выражаются через другие.
По-Вашему получается, что не "всем", но "всем, кроме оптимизатора". Который почему-то обязан от этого сглупить.

Локшин Марк softwarerЕсли мы сравниваем синтаксисы, так или иначе говорим о "лучше было бы везде использовать единый синтаксис, и это должен быть такой-то", то повторю - любой аргумент вида "лучше в 1% случаев" должен быть очень весок, чтобы перебороть "хуже во всех оставшихся случаях".
А зачем хуже? Достаточно - лучше в некоторых, и не хуже в остальных.
Было бы достаточно. Но поскольку "не хуже в остальных" отсутствует - недостаточно.

Локшин МаркОбещаю, более того, наблюдал такое поведение в MS SQL, правда на более сложных запросах.
Хм. Вы кажется обещали, что оптимизатор навернется "у меня", а не "в MS SQL". Если говорить о последнем - согласно утверждениям pkarklin *= в нем просто плохо реализован (недостаточно функционален). Лично я сделал в MSSQL один проект, имея целью в основном пощупать работу с ним, и ничуть не огорчусь, если больше никогда не доведется иметь с ним дело.

Локшин МаркНу а про ответ, я думаю, Вы догадываетесь?
Догадываюсь. Привел как раз чтобы показать, что с точки зрения "управления оптимизатором" продемонстрированное Вами преимущество имеет и оборотную сторону, и приходится таки использовать запись "в моем стиле".

Локшин МаркТак потому что такой способ записи порождает неоднозначности в интерпритации запроса, что есть очень плохо - значит способ записи дурной. Было бы весьма странно, если бы сервер его исполнял то так, то этак.
Хм. Я перестал понимать, то ли я идиот, то ли Microsoft так старательно затуманил простую вещь, то ли это делаете Вы. Насколько я вижу, Вы говорите примерно следующее: "выражение 1/0 не может быть однозначно интерпретировано, а следовательно способ записи a/b дурной". Я этой логики не понимаю, поэтому предлагаю свернуть эту часть обсуждения.

Да, последний вопрос: обрабатывал ли такие запросы MSSQL когда-нибудь или таки во всех версиях выдавал ошибку?

Ну и где? Где отношение d? Где переименование?
Кажется, наконец-то до меня дошло, что Вы уделяете очень большое значение форме. Увы, в рамках такой концепции ответить не смогу, поскольку предпочитаю говорить о сути.

В моем понимании мира - отношение d внутри скобок, а переименование там, где этот селект будет использован.

Локшин МаркЕсли Вы думаете, что оптимизатору преобразовать запрос к эквивалентному, который быстрее выполняется очень просто, то Вы ошибаетесь.
Если Вы полагаете, что я имел в виду именно это, то Вы ошибаетесь; если не полагаете, то наводите тень на плетень.

Я полагаю, что любой хороший алгоритм обязан на эквивалентных данных давать одинаковый результат. Гиперболизируя - если алгоритм зависит от того, записана ли в SQL константа как "1", "1.0" или "1E0", это хреновый алгоритм.

Локшин МаркТак зачем его еще и путать лишний раз?
Кстати, почему Вы считаете "путать"? Если есть неэквивалентность - 50% шансов за то, что именно "моя" запись даст более эффективный план.

Локшин МаркУверен, что рано или поздно и в Oracle навернется.
Ну.. удачи. Как я понимаю, Вы предлагаете ухудшать каждое приложение, основываясь на лично Вашей уверенности, что "иначе рано или поздно навернется". Для меня это чем-то сродни предложению окружать каждую подпрограмму пустым блоком отлова исключений.

Локшин МаркМмм... эээ.... а где я говорил, что я не использую подзапросов?
А где я говорил, что Вы их не используете?

Вы показали, что "такая запись может быть лучше, потому что". Я показал, что она по этой же причине может быть хуже. Какой из этого следует вывод? С моей точки зрения - "этот аргумент не позволяет судить о преимуществах той или иной записи".

mirУдивлен, что есть радикалы (softwarer), с фразами вроде "Увидев natural join в боевом коде, лично я испытаю сильное желание выкинуть автора этого кода за дверь." Такое значение незначительному вопросу? Это что-то больше психологическое, чем технологическое.
Вы, безусловно, можете считать это незначительным вопросом. Я же считаю это непониманием технологии разработки качественного программного обеспечения. Запрос, использующий natural join в любом его виде, может быть затронут (стать неверным) из-за мелкого изменения в БД либо в удаленной по тексту части этого запроса. Его использование в боевом коде - примерно то же, что передача параметров подпрограммы через разделяемые глобальные переменные.

Локшин МаркЗаметим на 0, а на все остальные числа - можно. Т.е. какие-либо проблемы появляются при конкретных значениях переменных. Запись с *= неоднозначна при любых значениях
"Значением" в случае этой операции является связываемая таблица. И запись неоднозначна далеко не при всех значениях, скорее при "очень некоторых".

Локшин МаркКак будет выглядит критерий для *= соединения?
Подключаемая по внешнему соединению таблица соединяется с одной и только с одной базовой таблицей.

Локшин МаркКакова сложность его проверки "в уме"?
Хм. Этот вопрос меня немного смущает. Дело в том, что этот критерий проверяется без участия ума, просто глазами, ну а сервер со своей стороны проведет ровно ту же проверку.

Локшин МаркТогда Вы по всей видимости должны знать, что хороших с вашей точки зрения алгоритмов исполнения запроса еще не изобретено...
Достаточно хорошие - изобретены. Идеальных, конечно, нет.

Локшин МаркОпять же, аналогия несколько натянута.
Это не аналогия, а гипербола (в моем тексте было употреблено именно это слово). Гиперболе, если угодно, по статусу положено быть несколько натянутой; ее предназначение - выпятить нечто, что в исходном объекте недостаточно заметно.

Локшин МаркВы рассуждаете как в том анекдоте "Какова вероятность встретить динозавра, выйдя на улицу...".
Безусловно. В данном случае Вы занимаете довольно категоричную позицию - "ухудшит и все тут", которой я противопоставляю столь же категоричную "а с тем же успехом и улучшит".

Скажем так, оптимизаторы имхо весьма преуспели в разворачивании подзапросов (Вы собственно говорите об этом дальше) и практически мне иногда приходилось запрещать оптимизатору такой разворот, но не припомню, чтобы приходилось понуждать его.

Локшин МаркТак что в свете вышесказанного я не понимаю, почему это ухудшение.
Наверное, мне следовало быть более аккуратным в формулировках. С точки зрения эффективности я нисколько не собираюсь настаивать на каком-то обязательном ухудшении ситуации при использовании ansi join-ов. Я в данном случае имел в виду тему более ранней части беседы - удобство их использования, читаемость запросов итп.

Локшин Марк...... А если вложенность побольше сделать? Запутается, и глазом не моргнет.
Итого: имеем некий незначительный процент запросов, на которых оптимизатор имеет шанс запутаться. Некоторые наверное таки запутаются. Имеем выбор: то ли помочь оптимизатору в конкретных редких случаях, тем же хинтом, то ли строить всю технологию под конкретный редкий случай.

Не сказал бы, что второй вариант выглядит однозначно верным выбором.

Локшин МаркБрр... ничего не понял. Выше я привел свой вариант, чем он хуже? Не обойтись без подзапроса - пишите подзапрос.
Хм. Давайте вспомним сначала. Вы обосновываете точку зрения, что join-синтаксис лучше, согласны?

Сначала Вы попытались показать, что он позволяет НЕЧТО. Я показал, что это НЕЧТО возможно и в where-синтаксисе. Тогда Вы начали обосновывать то, что вариант с подзапросом хуже. Я показал, что и в join-ах отказаться от подзапросов не удастся. Жду нового принципиального аргумента...

Если принципиальных аргументов нет - остается то, о чем говорю я, то есть аргументы количественные. Если, допустим, "скобки в 10% хуже" - это одно; если "скобки в 10% хуже, но в join-ах в 10% случаев их все равно приходится использовать" - это уже немного другое. Хотя в любом случае напальцевые рассуждения о весах, вопрос вкусов в чистом виде.

Локшин МаркПросто мне не нужно думать, когда *= написать, а когда left join, т.к синтаксис с *= неоднозначен
Вернулись к вопросам религии. Мне точно так же не нужно думать, когда писать (+), а когда left join, поскольку второй я никогда (исключая эксперименты в подобных беседах) не пишу.

Локшин МаркЯ лучше над другими вещами подумаю.
Угу. И эти вещи будут - как понять запрос, в котором относящиеся к одному и тому же условия разнесены на полторы страницы.

Локшин Марк softwarerИ запись неоднозначна далеко не при всех значениях, скорее при "очень некоторых".
Я имел ввиду конкретный пример, который привел выше.
Выберете уж что-нибудь одно. Если неоднозначно в конкретном примере - значит, конкретный пример a/0 точно так же дискредитирует запись вида a/b. Если для a/b действует аргумент "неопределен только в некоторых случаях" - значит, и для (+) некоторые случаи не являются основанием для глобальный выводов.

Локшин МаркМаловата будет (c). Часто требуется больше.
И насколько часто? Конечно, зависит от схемы данных, но.... верну Вам пассаж про то, что когда подзапросы необходимы - они необходимы и надо их писать.

Кстати, подкину еще одну задачку к размышлению. Если именно неоднозначность так пугает и является основным показанием к введению нового синтаксиса, возникает вопрос: а почему, собственно, не сделали совершенно тривиального действия и не разрешили эту неоднозначность точно так же, как она разрешается в join-ах?

Локшин МаркПишу запросы не выходя из коматозного состояния что-ли? Меня вот Ваш ответ смущает.
Хм. Когда Вы пишете запросы, много ли Вы думаете о том, каким пальцем на какую кнопку нажать? О том, правильно ли Вы написали слово SELECT или с ошибкой? Если да - а остается ли у Вас время подумать о деле?

Я абсолютно уверен, что у любого достаточно опытного человека технические действия выполняются на автомате, без явного мыслительного процесса. Например, я уверен, что Вы выбираете нужный вариант - LEFT или RIGHT JOIN - на автомате, в то время как меня неизменно удивляет, какие шутники назвали операцию "присоединение справа" LEFT JOIN-ом.

Локшин МаркНу про сервер никто не говорит.
Так уж и никто? :)

Вы говорите о вопросе, который значим не более, нежели проверка правильности написания слова SELECT. Но если второе Вы почему-то доверяете пальцам и серверу, то первое позиционируете как основание для кардинальной переделки существующего.

Локшин МаркЭ... погодите. IMHO у Вас все же проскакивает мысль, что я считаю, что "от подзапросов можно отказаться". Это не так, просто не нужно их (IMHO) необоснованно вводить.
Хм. Проскальзывает - неподходящее слово. Видимо, стоит объяснить схему рассуждений более явно.

Мы рассуждаем о различиях между некими двумя подходами. Различия - бывают качественные и количественные. Например, то, что маркетологи посоветовали не реализовывать full outer join через (+) - это качественное различие; разумеется, если потребуется, я покажу, как достаточно хорошо расписать его через (+), но объективно такая возможность не предусмотрена; это качественное отличие.

В том, на что Вы отвечаете, я показал, что качественного отличия между вариантами нет. Если бы "подзапросы против отсутствия подзапросов" - это было бы качественное различие; если же "обоснованные подзапросы здесь против обоснованных подзапросов там" - различие количественное, и максимум можно попробовать оценить, сколько их там и здесь.

Разумеется, Вы имеете право назвать "подзапросы здесь" необоснованными. Это сугубо религиозный аргумент. Что значит религиозный: основанием для него является вера в то, что "делать нужно так", и все что не соответствует этому объявляется необоснованным.

Локшин Марк softwarerУгу. И эти вещи будут - как понять запрос, в котором относящиеся к одному и тому же условия разнесены на полторы страницы.
Да и у Вас также получится с подзапросом,
Хм. Для экономии времени не собираюсь возражать на "получится с подзапросом". Вместо этого укажу, что у меня это получится только с подзапросом (то есть в тех отдельных случаях, когда нужен "неоднозначный outer join"), в то время как у Вас это будет получаться в каждом большом запросе, даже вообще без единого outer join-а.

Локшин Маркпричем часть условий соединения во FROM, часть в WHERE перемешанные с условиями фильтрации будут.
А вот этот аргумент меня очень огорчает. Потому что на предыдущей странице я обосновал (во всяком случае, возражений не последовало), что имено в WHERE существует свобода записи, позволяющая расписать условия именно исходя из максимальной логичности, понятности записи. Вы сейчас просто игнорируете ранее достигнутое и утверждаете прямо противоположное так, словно это аксиома.

Локшин МаркИ отношение вы переименовываете, т.е. по человеку изучая запрос нужно помнить что Вы и как переобозначили по отношению к стандартной схеме БД.
Хм. Во-первых, переименовывать совершенно не обязательно - с моей точки зрения это помогает ясности, но если Вам так больше нравится, никто не мешает использовать тривиальное переименование, сам в себя. Во-вторых, я не очень понимаю, чего именно Вы избегаете; можно предположить, что Вы имеете в виду использование в запросах для квалификации имен таблиц, то есть пишете что-то типа


Я избегаю как раз такого вот заикания. Причин для этого две - во-вторых, этот подход становится неприменимым при нескольких подключениях в запрос одной и той же таблицы, а во-первых я полагаю более практичным использовать значимые с точки зрения роли в конкретном запросе алиасы и сокращать ими запись, фокусируя внимание на собственно сути запроса.

vadiminfoДаже если в запросе участву.т проекции? Т.е. строгий перечень полей
Даже. Потому что альтернатива - добавляя необходимое поле в подзапрос, не забыть отмотать текст на пару страниц вниз и посмотреть, не участвует ли этот запрос в natural join, после чего отмотать на страницу вверх и посмотреть, нет ли случайно одноименного поля в другом подзапросе. И это необходимо делать каждый раз из-за того, что его автор поленился один раз набрать несколько дополнительных символов. Ну а тем временем другой программист, решив, что во втором подзапросе использован не очень удачный алиас, переименовывает его и таки ломает natural join.

vadiminfoизменеие, которых в любом случае сделает и другие запросы "неверными" (скорей всего при таких изменниях БД и запросы нужны другие)
Да бросьте. Добавление нового поля в таблицу или в запрос - если и не самая частая операция мелкой доработки, то точно одна из таковых.

vadiminfoТрудно представить себе качественное программное обеспечение с использованием (+). Это все-таки рудименты прошого, отвегнутые в стандартах.
Стандарт на перебегание улицы перед идущим автотранспортом вовсе не убедит меня рисковать своей жизнью. Вас убедит?

vadiminfoА без стандартов о каком качестве можно говорить?
Простите, демагогия.

vadiminfo(+) тогда тоже можно сравнить с заплатками в коде - использовались за не имением лучшего. Даже производители не рекомендуют. Какое там еще качество боевого кода?
Сравните, не возражаю. Собственно классический вопрос - Вам шашечки или ехать? Мне - ехать, то есть хорошо работающую, качественную программу. Вам....

Чтобы обосновать Ваше утверждение, Вам придется доказать, что использование нестандартизованной фичи есть нарушение стандарта ANSI SQL, нарушение стандарта ANSI SQL эквивалентно работе "без стандартов вообще", а работа "без стандартов вообще" неизбежно ведет к некачественному коду. Сумеете? Как минимум второй пункт вызывает у меня большие сомнения.