Явные соединения против неявных объединений?

Question

Профессор базы данных сказал нам использовать:

SELECT A.a1, B.b1 FROM A, B WHERE A.a2 = B.b2;

Вместо:

SELECT A.a1, B.b1 FROM A INNER JOIN B ON A.a2 = B.b2;

Предположительно, Oracle не любит синтаксисы JOIN, потому что эти синтаксисы JOIN сложнее оптимизировать, чем ограничение WHERE декартового произведения.

Я не могу себе представить, почему это так. Единственная проблема с производительностью может заключаться в том, что анализатору необходимо проанализировать еще несколько символов. Но это незначительно в моих глазах.

Я нашел это вопросы о переполнении стека:

• Существует ли официальная рекомендация Oracle по использованию явных соединений ANSI против неявных объединений?
• Явные и неявные объединения SQL

И это предложение в документации Oracle: https://docs.oracle.com/cd/B19306_01/server.102/b14200/queries006.htm

Oracle рекомендует использовать синтаксис OUTER JOIN предложения FROM, а не оператор соединения Oracle.

Может кто-нибудь дать мне последние рекомендации от Oracle со ссылкой. Потому что она не признает StackOverflow (здесь может ответить каждый) и документация 10g устарела в наших глазах.

Если я ошибаюсь и Oracle действительно не любит JOINS сейчас, то это тоже нормально, но я не нахожу статей. Я просто хочу знать, кто прав.

Большое спасибо всем, кто может мне помочь!

Answer 1

Средний sql-запрос, с которым вы столкнетесь в реальном бизнесе, имеет 7-8 соединений с 12-16 условиями соединения Один из каждых 10 или 20 запросов может включать в себя вложенные объединения или другие более сложные случаи. Явный синтаксис соединения гораздо проще поддерживать, отлаживать и развивать. И эти факторы имеют решающее значение для программного обеспечения для бизнеса - чем быстрее и безопаснее, тем лучше. Неявное соединение несколько проще в коде, если вы создаете операторы динамически через код приложения. Возможно, есть другие способы использования, которые я не знаю.

Answer 2

Как и во многих нетривиальных вещах, нет простого ответа да / нет.

Первое, для тривиальных запросов (как ваш пример в вопросе), не имеет значения, какой синтаксис вы используете . Классический синтаксис еще более компактен для простых запросов.

Сначала для нетривиальных запросов (скажем, более пяти объединений) вы узнаете о преимуществах синтаксиса ANSII . Основное преимущество заключается в том, что предикаты объединения отделены и отделены от условия WHERE.

Простой пример - это полный действительный запрос в синтаксисе, предшествующем ANSII

SELECT A.a1, B.b1 
FROM A, B 
WHERE A.a1 = B.b1 and
      A.a1 = B.b1(+);

Это внутреннее или внешнее соединение? Кроме того, если эта конструкция разбросана в предикате с 10 другими условиями соединения в предложении WHERE, ее даже очень легко неправильно прочитать.

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

Да, и были времена (о Oracle 10), вы должны быть осторожны. Но во времена 12 и 18 версий я не вижу причин для защиты, и я убедился, что безопасно использовать синтаксис ANSII из вышеприведенной причины лучшего обзора и читабельности.

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

Answer 3

Ваш профессор должен поговорить с Гордоном Линоффом, который является профессором информатики в Колумбийском университете. Гордон и большинство энтузиастов SQL на этом сайте почти всегда говорят вам использовать явный синтаксис объединения. Причин для этого много, в том числе (но не ограничиваясь ими):

• Явные объединения упрощают просмотр логики объединения. С другой стороны, неявные объединения запутывают логику объединения, распределяя ее по предложениям FROM и WHERE.
• Стандарт ANSI 92 рекомендует использовать современные явные объединения, и фактически не одобряет неявное соединение, которое, по-видимому, продвигает ваш профессор

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