maytonВобщем и хотя Оракл поддерживает синтаксис JOIN - его знающие Oracle девелоперы не используют 99.9% я гарантирую это...
Ну не факт.

1. Есть ситуации LEFT JOIN, которые в ANSI синтаксисе можно написать, а через (+) нельзя. Ну или _очень_сильно_ извращаясь, а в Ansi синтаксисе все понятно, просто и даже работает.
2. Для начинающих людей ANSI синтаксис значительно понятнее. В свое время, когда нужно было делать отчеты для пром. системы - всех учил именно ANSI синтаксису.

3. Т.ч. на мой взгляд, ANSI синтаксис в Oracle необходим. И иногда приходится им пользоваться.

softwarerЯ много лет прошу всех встречных привести мне реальный разумный пример такой задачи. Если коротко, ни разу не услышал ничего вменяемого.
AFAIK Такое может встретиться, если кто-то решил в структуре БД на строковых полях повторить троичную булевую логику )))
1. Строка символов - данные
2. Пустая строка символов - просто данные пустые
3. null - что-то другое (например: "данные просто еще не введены", их требуется ввести).

Такую структуру БД, разумеется, портировать на Oracle будет проблематично.

Dimitry SibiryakovЧуть выше сообщения по ссылке была ещё одна ссылка на список случаев применения
стандартного синтаксиса в которых Оракул в лучшем случае падает, а в худшем - выдаёт
неправильный результат.

Понятие "стандартный" и "падает" вещь относительная.

Можно найти 100500 случаев, в которых Oracle выполнить "стандартный" запрос. А остальные БД не выполнят. Например "встанут колом" ))). И никакой "стандарт" и "стандартный синтаксис" тут не поможет.

IMHO & AFAIK

softwarerLeonid Kudryavtsev1. Есть ситуации LEFT JOIN, которые в ANSI синтаксисе можно написать, а через (+) нельзя.
Отдел сказок на втором этаже. Эту я слышу уже лет двадцать, и в итоге каждый раз оказывается, что "нельзя" следует читать как "я не умею и вообще не подумал".

AFAIK Ситуация, когда по outer join нужно связать одну таблицу с несколькими. В Ansi Join это прописывается элементарно, если тупо заменить на (+) получаем ORA-01417. Ситуация редкая, но пару раз мне такие запросы делать пришлось. Без достаточно извращенных подзапросов или временный таблиц мне было и не написать. Если я правильно помню, даже с подзапросами было не все гладко, вроде Oracle их раскрывать пытался и все работало не совсем предсказуемым образом.

Но ANSI синтаксис, в любом случае, намного понятнее. Лично мне и тем, кого я знаю. Кроме того, в Ansi синтаксисе значительно сложнее сделать ошибку. При сложном запросе (скажем 10-15 таблиц) пропустить какое либо условие достаточно просто, а найти ошибку крайне сложно. В ANSI синтаксисе и сложнее пропустить условие связи (т.к. все описываются в отдельных секциях), и проще такую ошибку отловить, и текст запроса IMHO намного более структурированный и понятный.

Yo.!kdvLeonid Kudryavtsev,

пример: Фамилия, Имя, Отчество. Не у всех есть отчество (null), но оно может быть просто не введено (пустая строка). Понять, что отчество "не введено" при '' = null невозможно.
а потом эти данные экспортируются в соседнюю систему и начинается гадание на кофейной гуще, что бы могло означать нулл, а что пустая строка. может пустая строка введено, но отсутсвует, а нулл - забыли ввести ? а может наоборот. а может просто дурной дизайн субд, которая устраивает геморой на пустом месте.
Полностью поддерживаю

Особенно интересно, как в таком дизайне делать интерфейс пользователя. Когда есть поле для ввода, а дальше гадайте, что Вы перед собой видите "просто пустую строчку" или null

Крайне доставляло в Web-системе двойные пробелы в БД. На экране (html) они схлопывались, а в БД оставались повторы. Пользователи долго не могли понять, почему они делают просто copy/past, а данные система найти не может )))

Аналогично пустые пробелы в конце строк

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

p.s. Один из коллег, говорил, что ходить по граблям т.к. это устаревшая технология разработки. Он предлагал ходить по обручам от бочек. Говорил, что это доставляет больше удовольствий )))

mayton...Несколько мыслей. Есть чистая теория. Т.н. реляционная алгеба. Она определяет операцию реляционного
деления. Одну таблицу делим на другую и получаем отношение. Есть также у нее свой смысл и своё
теоретическое обоснование как умножение и деление кватернионов и октав в алгебре векторов.
Но она (операция деления) не имеет своей имплементации в стандартах SQL. В SQL-ях
нет операции DIVIDE, DIVISION e.t.c.

Что это? Нарушение AnsiSQL принципов РА? Или просто адаптация стандарта под аппаратную базу?

Я не знаю.
Ну ты и загнул.... )))