SQL альтернатива левому соединению

Question

SQL альтернатива левому соединению

0

У меня есть этот запрос, который выполняет left join по таблицам и возвращает некоторые строки.

Запрос с левым соединением:

Select DISTINCT 
e.id,e.name
from employee e
left join
job j on j.id = e.id
where e.id like 'D%'

Теперь для одного и того же запроса я хотел получить результат без использования left join и я смог создать этот SQL-запрос, который дал мне тот же результат, что и указанный выше запрос.

Запрос без левого соединения:

Select DISTINCT 
e.id,e.name
from employee e, job j
where e.id like 'D%' AND (e.id=j.id  OR  e.id <> j.id)

Хотя запрос возвращает тот же результат, что и выше, мой вопрос заключается в следующем: имеет ли смысл второй запрос и является ли он эквивалентным левому соединению?

Allan Fernandes 21 фев. 2018, в 18:27

Источник

2

Почему бы вам не использовать LEFT JOIN ? Не используйте второй запрос.
Eric 21 фев. 2018, в 16:56
0

Возможная копия ANSI против не-ANSI синтаксиса SQL JOIN
Pred 21 фев. 2018, в 16:57
1

Вы можете получить тот же результат без LEFT JOIN , просто удалив его: Select DISTINCT e.id,e.name from employee e where e.id like 'D%' (вы, вероятно, тоже можете удалить DISTINC) совершенно бесполезно, когда вы удалите DISTINCT, вы увидите, что он почти такой же, как CROSS JOIN (удаляются только любые возможные NULL идентификаторы)
dnoeth 21 фев. 2018, в 17:01
0

Если вы не выбираете и не фильтруете что-либо из таблицы заданий, зачем вам это нужно в запросе?
isaace 21 фев. 2018, в 17:03
0

@Eric - на самом деле я пытаюсь оптимизировать запрос, поэтому хотел увидеть производительность без левого соединения.
Allan Fernandes 21 фев. 2018, в 17:04
0

@Pred Я обязательно посмотрю на это. Спасибо
Allan Fernandes 21 фев. 2018, в 17:04
0

@dnoeth - Это то, о чем я думал, так что это все равно принесет мне тот же результат, верно? без использования AND (e.id=j.id OR e.id <> j.id) . Я попробую это и вернусь к вам. Благодарю.
Allan Fernandes 21 фев. 2018, в 17:06
0

@AllanFernandes Вы выполняете LEFT JOIN , вы просто не указываете это явно в запросе. В большинстве RDBMS не будет заметной разницы в производительности, однако, более старый синтаксис устарел, и вы можете найти несколько статей, описывающих его подводные камни.
Pred 21 фев. 2018, в 17:07
0

@Pred: Где вы видите неявное левое соединение? Второй вариант выбора объединяет каждый NOT NULL-идентификатор сотрудника с каждым NOT NULL-идентификатором из задания, которое является перекрестным соединением, но не внешним соединением.
dnoeth 21 фев. 2018, в 19:39
0

@dnoeth В условиях where :: (e.id=j.id OR e.id <> j.id) Попробуйте найти различия между соединениями ANSI и не-ANSI.
Pred 21 фев. 2018, в 20:46
0

@prad: я знаю различия (между прочим, старый синтаксис по-прежнему является стандартным SQL), и # 2, использующий явный синтаксис объединения, переводится в: from employee e join job j on (e.id=j.id OR e.id <> j.id) . Каждое значение в e.id будет соответствовать каждому значению в j.id, egeid: 1, j.id: 1,2,3,4,5 -> 1 = 1, 1 <> 2, 1 <> 3, 1 <> 4, 1 <> 5 -> все пять строк совпадают., Это то же самое, что e join j on e.id is not null and j.id is not null
dnoeth 21 фев. 2018, в 21:27

Показать ещё 9 комментариев

Теги:

mysql

sql

join

left-join

1 ответ

Ещё вопросы

Почему бы вам не использовать LEFT JOIN ? Не используйте второй запрос.
Возможная копия ANSI против не-ANSI синтаксиса SQL JOIN
Вы можете получить тот же результат без LEFT JOIN , просто удалив его: Select DISTINCT e.id,e.name from employee e where e.id like 'D%' (вы, вероятно, тоже можете удалить DISTINC) совершенно бесполезно, когда вы удалите DISTINCT, вы увидите, что он почти такой же, как CROSS JOIN (удаляются только любые возможные NULL идентификаторы)
Если вы не выбираете и не фильтруете что-либо из таблицы заданий, зачем вам это нужно в запросе?
@Eric - на самом деле я пытаюсь оптимизировать запрос, поэтому хотел увидеть производительность без левого соединения.
@Pred Я обязательно посмотрю на это. Спасибо
@dnoeth - Это то, о чем я думал, так что это все равно принесет мне тот же результат, верно? без использования AND (e.id=j.id OR e.id <> j.id) . Я попробую это и вернусь к вам. Благодарю.
@AllanFernandes Вы выполняете LEFT JOIN , вы просто не указываете это явно в запросе. В большинстве RDBMS не будет заметной разницы в производительности, однако, более старый синтаксис устарел, и вы можете найти несколько статей, описывающих его подводные камни.
@Pred: Где вы видите неявное левое соединение? Второй вариант выбора объединяет каждый NOT NULL-идентификатор сотрудника с каждым NOT NULL-идентификатором из задания, которое является перекрестным соединением, но не внешним соединением.
@dnoeth В условиях where :: (e.id=j.id OR e.id <> j.id) Попробуйте найти различия между соединениями ANSI и не-ANSI.
@prad: я знаю различия (между прочим, старый синтаксис по-прежнему является стандартным SQL), и # 2, использующий явный синтаксис объединения, переводится в: from employee e join job j on (e.id=j.id OR e.id <> j.id) . Каждое значение в e.id будет соответствовать каждому значению в j.id, egeid: 1, j.id: 1,2,3,4,5 -> 1 = 1, 1 <> 2, 1 <> 3, 1 <> 4, 1 <> 5 -> все пять строк совпадают., Это то же самое, что e join j on e.id is not null and j.id is not null

Gordon Linoff · Accepted Answer · 2018-02-21T15-12-00.000Z

Я думаю, что exists более естественный метод:

Select e.id, e.name
from employee e
where exists (select 1 from job j where j.id = e.id) and
      e.id like 'D%';

Это также должно иметь гораздо лучшую производительность.

РЕДАКТИРОВАТЬ:

Дноет делает действительно хороший момент. Я пропустил "левый" в left join. Самый простой запрос:

Select e.id, e.name
from employee e
where e.id like 'D%';

Я ожидал бы, что id будет уникальным, поэтому select distinct не нужно.

Производительность может быть лучше, но это даст другой результат, то есть внутреннее соединение. Но исходный Select точно такой же, как Select e.id,e.name from employee e where e.id like 'D%' (при условии, что id - это уникальный столбец). Нет доступа к столбцу из внутренней таблицы, поэтому нет необходимости присоединяться вообще. Достойный оптимизатор (конечно, не тот, что в MySQL) сделает это устранение соединений автоматически.
@dnoeth. , , Вы абсолютно правы. Я корректировал ответ, ссылаясь на ваш комментарий.