Внутреннее соединение против Где

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

В PostgreSQL определенно нет разницы - они оба соответствуют одному и тому же плану запроса. Я на 99% уверен, что это относится и к Oracle.

Они должны быть точно такими же. Однако в качестве практики кодирования я бы предпочел присоединиться. Он четко формулирует ваши намерения,

Они оба являются внутренними объединениями, которые делают одно и то же, один просто использует новый синтаксис ANSI.

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

Они логически идентичны, но в более ранних версиях Oracle, которые использовали синтаксис ANSI, часто возникали ошибки в более сложных случаях, поэтому вы иногда столкнетесь с сопротивлением со стороны разработчиков Oracle при его использовании.

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

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

И снова я не знаю конкретно Oracle, но я знаю, что версия SQL Server старого стиля левого соединения ошибочна даже в SQL Server 2000 и дает несогласованные результаты (иногда левое соединение, иногда перекрестное соединение), поэтому оно никогда не должно быть использовал. Надеюсь, Oracle не страдает той же проблемой, но определенно левое и правое объединение может быть намного сложнее правильно выразить в старом синтаксисе.

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

Использование JOIN упрощает чтение кода, поскольку он не требует пояснений.

Нет разницы в скорости (Я только что проверил это) и план выполнения такой же.

Верно, что функционально оба запроса должны обрабатываться одинаково. Однако опыт показал, что если вы выбираете из представлений, использующих новый синтаксис соединения, важно также структурировать свои запросы с его использованием. Оптимизатор Oracle может запутаться, если представление использует оператор "join", но запрос, обращающийся к представлению, использует традиционный метод объединения в предложении "where".

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

Также можно избежать непреднамеренных декартовых произведений, используя версию соединения.

Третий эффект - облегчение чтения SQL с более простым условием WHERE.

Нет! Тот же план выполнения, посмотрите на эти две таблицы:

CREATE TABLE table1 (
  id INT,
  name VARCHAR(20)
);

CREATE TABLE table2 (
  id INT,
  name VARCHAR(20)
);

План выполнения запроса с использованием внутреннего соединения:

-- with inner join

EXPLAIN PLAN FOR
SELECT * FROM table1 t1
INNER JOIN table2 t2 ON t1.id = t2.id;

SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);

-- 0 select statement
-- 1 hash join (access("T1"."ID" = "T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2

И план выполнения запроса с использованием предложения WHERE.

-- with where clause

EXPLAIN PLAN FOR
SELECT * FROM table1 t1, table2 t2
WHERE t1.id = t2.id;

SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);

-- 0 select statement
-- 1 hash join (access("T1"."ID" = "T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2

Не забывайте, что в Oracle, если атрибуты ключа объединения названы одинаково в обеих таблицах, вы также можете записать это как:

select *
from Table1 inner join Table2 using (ID);

Конечно, и у него такой же план запроса.

[За бонусный балл ...]

Использование синтаксиса JOIN позволяет вам более легко закомментировать соединение, так как все оно находится в одной строке. Этот может будет полезен, если вы отлаживаете сложный запрос.

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

Хотя идентичность двух запросов кажется очевидной, иногда случаются странные вещи. Я пришел к запросу, который имеет разные планы выполнения при перемещении предиката соединения из JOIN в WHERE в Oracle 10g (для плана WHERE лучше), но я не могу воспроизвести эту проблему в упрощенных таблицах и данных. Думаю, это зависит от моих данных и статистики. Оптимизатор - довольно сложный модуль и иногда ведет себя волшебно.

Вот почему мы не можем ответить на этот вопрос в целом, потому что это зависит от внутреннего устройства БД. Но мы должны знать, что ответ должен быть «без отличий».

Сегодня у меня возникла эта загадка, когда я проверял тайм-аут одного из наших sp в продакшене, вместо этого заменил внутреннее соединение таблицы, построенной из xml-канала, на предложение 'where' .... среднее время выполнения теперь составляет 80 мс на 1000 выполнений, тогда как до того, как среднее время выполнения было 2,2 секунды ... основное отличие в плане выполнения - исчезновение ключевого поиска ... Сообщение о том, что вы не узнаете, пока не протестируете оба метода.

ваше здоровье.

В сценарии, где таблицы находятся в 3-й нормальной форме, соединения между таблицами не должны изменяться. Т.е. присоединиться к КЛИЕНТАМ и ПЛАТЕЖИ всегда должны оставаться неизменными.

Однако следует отличать присоединяется от фильтры. Объединения связаны с отношениями, а фильтры - с разделением целого.

Некоторые авторы ссылаются на стандарт (например, Джим Мелтон; Алан Р. Саймон (1993). Понимание нового SQL: полное руководство. Морган Кауфманн. Стр. 11–12. ISBN 978-1-55860-245-8.) , писал о преимуществах использования синтаксиса JOIN для таблиц, разделенных запятыми, в предложении FROM.

Я полностью согласен с этой точкой зрения.

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

Они оба присоединяются и делают то же самое.

Взгляните на Зачем в запросах MySQL использовать join вместо where?

Как сказал Кевик, план выполнения такой же.

Оператор JOIN только легче читается, что позволяет не забыть условие ON и получить декартово произведение. Эти ошибки довольно сложно обнаружить в длинных запросах с использованием нескольких соединений типа: SELECT * FROM t1, t2 WHERE t1.id = t2.some_field.

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

Именно поэтому использование оператора JOIN, безусловно, является лучшей практикой: лучшая ремонтопригодность и лучшая читаемость.

Более того, если я хорошо помню, JOIN оптимизирован в отношении использования памяти.

У меня есть дополнение к этому хороший ответ:

Это то, что определяется как SQL92 и SQL89 соответственно, между ними нет разницы в производительности, хотя вы можете опустить слово INNER (использование просто JOIN достаточно ясно, и в простейшем запросе вы сохраняете 5 нажатий клавиатуры, теперь представьте, сколько штрихов есть в большом единицы).