Существует ли официальная рекомендация Oracle по использованию явных соединений ANSI против неявных соединений? - PullRequest
16 голосов
/ 18 октября 2011

Примечание: я не прошу вас говорить мне «использовать явные объединения», но ищу официальную позицию Oracle, если таковая имеется по этому вопросу.

Из документации базы данных Oracle (также встречается в документации 9i и 11g):

Oracle рекомендует использовать синтаксис FROM clause OUTER JOIN вместо оператора соединения Oracle.На запросы внешнего соединения, использующие оператор соединения Oracle (+), распространяются следующие правила и ограничения […]

Другими словами, Oracle рекомендует использовать первую из этих двух форм:

FROM a LEFT JOIN b ON b.x = a.x
vs
FROM a, b WHERE b.x(+) = a.x

Однако я нигде не нашел в документации Oracle ни одной рекомендации использовать предпочтительно одну из этих двух форм:

FROM a INNER JOIN b ON b.x = a.x
vs
FROM a, b WHERE b.x = a.x

Есть параграф, который я пропустил?

Ответы [ 2 ]

10 голосов
/ 25 октября 2011

На сайте поддержки Oracle есть несколько замечаний о проблемах с синтаксисом соединения ANSI с обходными путями, рекомендующими использовать синтаксис оракула. ​​

Ошибка 5188321 неправильных результатов (без строк) ИЛИ ORA-1445 из внешнего соединения ANSI

Versions affected: Versions >= 9.2.0.1 but < 11 

Description
Wrong results or an ORA-1445 can be returned with a query involving a 
 very large select list count when ANSI OUTER JOIN syntax is used.


Workaround
  Use native oracle outer join syntax 
 or 
  reduce the select list count.

Ошибка 5368296 ANSI-соединение SQL может не сообщать ORA-918 для неоднозначного столбца

Versions affected: Versions < 11

Description

****
Note: This fix introduces the problem described in bug 7318276
      One off fixes for that bug address the issue here also.
****      

ORA-918 is not reported for an ambiguous column in a query 
involving an ANSI join of more than 2 tables/objects. 

eg:
 -- 2 table join, returns ORA-918
 SELECT  empno 
 FROM emp a JOIN emp b  on a.empno = b.empno; 

 -- 3 table join does not report ORA-918 when it should ...
 SELECT  empno
 FROM emp a JOIN emp b on a.empno = b.empno
            JOIN emp c on a.empno = c.empno;

Ошибка 7670135 Долгое время анализа при компиляции соединения ANSI

 Versions affected: Versions BELOW 11.2 

Description

A query having ANSI join(s) may take noticeable time during query compilation,
especially if the query includes an NVL() function.

Workaround:
 Use ORACLE join instead of ANSI join

Из Oracle Press - Oracle OCP 11g все в одном руководстве по экзаменам

enter image description here

И от Asktom (который не обязателен)

 Historically there have been bugs related to ANSI syntax, in fact even the 
 10.2.0.4 projected issues list includes 10 bugs/issues related to ANSI syntax.

 In the past I've encountered some of these bugs myself, and have continued to use 
 and advocate the "traditional" Oracle style.

 I'd like to know if you feel that the implementation of ANSI syntax is now equally    
 robust compared  to the traditional syntax.

 Followup   February 19, 2008 - 5pm Central time zone:
 unfortunately, there are bugs in non-ansi joins too, probably more than 10 in fact.

 I personally do not use the new syntax (except in the rare case of a full outer join, 
 a truly rare beast to encounter). I have no comment on it really. 

Смотрите также предыдущий вопрос по той же теме. Разница между Oracle плюс (+) и ANSI JOIN?

Я также нашел это утверждение в документе , но нет ссылки на то, откуда оно взято

"Начиная с Oracle 9i, Oracle рекомендует разработчикам SQL использовать синтаксис объединения ANSI вместо проприетарного (+) синтаксиса Oracle. Есть несколько причин для этой рекомендации, в том числе:

• Проще разделять и читать (без смешения и кода ограничения) • Легче правильно построить код соединения (особенно в случае «внешних» соединений) • Переносимый синтаксис будет работать на всех других ANSI-совместимых базах данных, таких как MS SQL Server, DB2, MySQL, PostgreSQL и др. • Поскольку это общепринятый стандарт, он является общей целью для инструментов всех будущих баз данных и сторонних поставщиков. • Собственный синтаксис Oracle external-join (+) Oracle может использоваться только в одном направлении за раз, он не может выполнить полное внешнее соединение • Плюс эти дополнительные ограничения из документации Oracle: o Оператор (+) может быть применен только к столбцу, а не к произвольному выражению. Однако произвольное выражение может содержать один или несколько столбцов, помеченных оператором (+). o Условие, содержащее оператор (+), нельзя объединить с другим условием с помощью логического оператора ИЛИ. o Условие не может использовать условие сравнения IN для сравнения столбца, отмеченного оператором (+), с выражением. o Условие не может сравнивать столбцы, помеченные оператором (+), с подзапросом. "

Таким образом, пришло время принять синтаксис соединения ANSI - и перейти в 21 век

8 голосов
/ 18 октября 2011

Я не видел его, если есть. В частности, причина предпочтительного синтаксиса ANSI для внешних объединений (кроме нестандартного, специфичного для Oracle символа (+)) заключается в том, что больше внешних объединений можно выразить с помощью синтаксиса ANSI. Ограничение «ORA-01417: таблица может быть внешне присоединена не более чем к одной другой таблице» применяется к (+) внешним соединениям, но не к внешним соединениям ANSI. Другие ограничения на (+), которые не применяются к внешним соединениям ANSI, задокументированы здесь .

Один очень уважаемый эксперт Oracle на самом деле рекомендует придерживаться старого синтаксиса для внутренних объединений - см. блог Джонатана Льюиса . Там он говорит, что объединения ANSI в любом случае преобразуются в традиционные объединения Oracle. Я не согласен с ним на 100% (я предпочитаю, чтобы ANSI присоединился к себе в целом), но не претендовал бы на долю его знаний по этой теме.

В двух словах, внешние объединения ANSI технически превосходят старые соединения (+), тогда как для внутренних объединений это больше вопрос стиля.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...