Leonid KudryavtsevСитуация редкая, но пару раз мне такие запросы делать пришлось
Но делали. И это как раз одна из тех вещей, которые бы стоило улучшить вместо того, чтобы приделывать ещё один синтаксис. Это ведь не какое-то идеологическое преимущество ansi-синтаксиса, это просто "в своё время недоделали и закрыли workaround-ом, а теперь вместо того, чтобы сделать нормально, приделали ansi-синтаксис с его проблемами и недостатками".

Leonid KudryavtsevНо ANSI синтаксис, в любом случае, намного понятнее
Могу лишь пожать плечами. Мне, например, каждый раз при встрече приходится напоминать себе, что против всех законов логики "left join" - это "присоединение справа", и я предпочитаю видеть все условия на таблицу вместе, нежели помнить, что в синтаксисе типа




три условия размещены в трёх местах и означают три разные по смыслу вещи. Наверное, можно сказать, что это дело привычки, во всяком случае доказать обратное будет затруднительно. Во всяком случае, если говорить о новичках и начинать с inner join, лично я не представляю, как объяснить ansi-синтаксис, чтобы он оказался удобнее и понятнее, нежели where-овский.

Leonid KudryavtsevЛично мне, вообще реалиционная алгебра и "SELECT" не нравятся. Т.к. отучают думать о структуре БД
Это довольно частый случай. Выглядит он примерно так: есть некоторое решение А. Все им пользуются, понаступали на грабли, изучили недостатки. Приобретённый опыт приводит к разработке решения Б, ликвидирующего эти недостатки, все радуются. Проходит сколько-то лет, приходит новое поколение, которое в какой-то степени обстучалось о недостатки подхода Б, но при этом не имеет личного опыта работы с А - и оно, забыв, не зная либо просто недооценивая его недостатки, начинает изобретать А заново, искренне уверенное, что так лучше.

Leonid Kudryavtsevпрограммист и все причастные должны были неизбежно думать о структуре БД, что было и не плохо.
Угу. И при любых изменениях требовалось править кучу мест в программе. Вот, скажем, недавно я сделал такую вещь: переименовал таблицу, создал вьюху над этой таблицей, в триггерах над вьюхой посадил отладочную печать и сделал синоним, который направлял то на вьюху (работая в отладке), то на таблицу (быстро и как прежде). И никто ничего не заметил. А в том, что описываете Вы, было бы легче повеситься :)

Leonid KudryavtsevТо в большинстве случаев для ввода данных и OLTP систем, как мне кажется, "select" это просто какое-то извращение. Сейчас, половина битвы за эффективность - это борьба С оптимизатором.
Я не очень представляю себе, как превратить ввод данных и однострочные запросы в борьбу с оптимизатором.

Симонов Денисвот это как раз не правильно.
Как бы Вам сказать.... 1, 2 и 3 - это вовсе не обязательно константы, это просто маркеры для отображения трёх по-разному работающих условий. Можно подставлять туда что угодно. А вот на тему "тогда верно"... как бы это деликатно сказать... если Вы действительно уверены, что надо только так и никак иначе, то почему такой синтаксис не запретили и всё будет нормально работать? :)

Leonid KudryavtsevНа мой взгляд именно "идеологическое преимущество" В Ansi синтаксисе очевиден (задан) порядок и условия соединения таблиц.
Это уже другая тема, не имеющая отношения к ORA-01417.

Что касается заданного порядка соединения, то это палка о двух концах: сужая возможности оптимизатору, она одновременно и облегчает ему работу, и лишает возможности построить наиболее эффективный план.

Leonid KudryavtsevА при наличие связи outer join вида "одна таблица со многими", результат будет зависит от того, в каком порядке мы обходим таблицы.
Скажу так: не понял мысли. Возможно, будет лучше, если Вы покажете пример того, что имеете в виду.

Leonid KudryavtsevМеня, как разработчика, и оптимизатор и select бесят. Мне не нужно, что бы оптимизатор как-то "догадывался" и делал предположения о структуре базы данных. Я, как разработчик, структуру базы данных _знаю_.
Когда разработчик отдаёт базу в продакшн, а через пару лет вдруг на неё смотрит, он бывает сильно удивлён :)

Leonid KudryavtsevВ этом плане, ANSI синтаксис как-бы шаг назад. Указали РУКАМИ порядок и условия объединения таблиц, из реалиционных таблиц программист руками собрал иерархическую структуру, вернули данные. Все руками программиста
Скажу коротко: никто не мешает оптимизатору выполнить соединения не так, как написано в join-ах. Я даже уверен, что любой вменяемый оптимизатор не сковывает себя таким образом. То, о чём Вы говорите - чисто визуальное ощущение, с тем же успехом можно потребовать, чтобы оптимизатор выполнял where-часть строго сверху вниз и точно так же "всё руками", синтаксис тут не при чём. На практике для желающих этого Оракл предусмотрел хинт ORDERED.

Leonid KudryavtsevОптимизатор видя запрос и глядя на таблицы пытается догадаться какая у них структура и как их эффективно связать.
Знаете, это немного наркоманская фраза :) Оптимизатор ни о чём не гадает, структуру таблиц и многое другое он точно знает.

Leonid KudryavtsevЯ не пытаюсь видеть "условия на таблицу". Мне на таблицу пофиг. Я пытаюсь понять структуру данных. Что, где и в какой последовательности размещено в БД. Своего рода кусок ER-диаграммы.
Запрос - не то место, глядя на которое надо "пытаться понять структуру данных". Для этого предназначены те самые ER-диаграммы и прочая документация.

Глядя на запрос, я хочу понимать логику этого запроса, логику выборки данных. И для этого мне очень удобно сначала прочитать, что в запросе участвуют ДОМА, ДВОРЫ и ДЕРЕВЬЯ (во from), потом прочитать, какие именно дома (несколько строк вместе в where), потом - какие именно дворы итп. В ansi-синтаксисе уже первое из этого - понять, какие сущности участвуют в запросе - уже требует нетривиальных усилий либо совершенно уродского форматирования.

Leonid KudryavtsevА вот за "условиями на таблицу" когда таблиц 10-15, за "деревьями леса не видно".
Именно. Типичная для ansi синтаксиса ситуация, когда куча условий забивает даже просто понимание, какие сущности участвуют в запросе.

Leonid KudryavtsevНу как-то на FoxPro приложения разрабатывали и не вешались
Не вешались. А теперь попробуйте взять и сделать какую-нибудь задачу на "тех" инструментах. На пятом турбо паскале. На шестом майкрософт си. На клиппере. Не пример на две минуты, а просто задачку на несколько часов хотя бы. И очень быстро ощутите, что "а теперь бы повесился".

Leonid Kudryavtsev"однострочные запросы" давно пытаюсь не делать
Ну, тем не менее это естественная, правильная и даже пожалуй что основная составляющая oltp-запросов.

Leonid KudryavtsevБыло решено изменением интерфейса. При этом, никаких претензий от аналитиков (пользователей?) не возникло. Юзабилити не пострадало.
Ну вот и давайте отметим, что синтаксис соединений тут не при чём :)

Симонов Дениси результат такого запроса будет отличаться от того если бы условие t2.b = 2 переместили в секцию where.
Да, именно об этом я и писал в том посте, который вызвал Ваше "неправильно". Теперь Вы это повторяете. Смысл беседы?

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

Leonid KudryavtsevПолучить .DLL размером в пару мегабайт и/или в 10-20 Kb - в общем, разница есть
Не особо. Если, конечно, вопрос не в том, что делаешь двадцать dll размером в пару мегабайт каждая.

Leonid Kudryavtsevа половина памяти "отъедается" VCL который пришел вместе с _единственным_ вызовом одной ф-ции на C++ Builder'е, которая требуется для загрузки приложения.... можно конечно и так жить ))),
В этом месте уже совершенно очевидно правильное решение - медленно элиминировать того идиота, кому нужно тащить в проект отдельных инструмент ради "одной функции для загрузки приложения". Ну и мелочи, типа - держать в памяти до конца работы то, что нужно только при загрузке. В общем, фигня на фигне фигнёй погоняет.

Отдельный интерес - как собрать эту DLL так, чтобы она "занимала половину памяти" хотя бы в виде файла на диске.... я уж не говорю про то, сколько она будет на самом деле занимать в памяти. Я вот пожалуй не возьмусь представить, что надо запихать, чтобы "ради одной функции" собралось 16 метров. У меня полнофункциональные приложения гораздо меньше :)