Явные и неявные SQL-соединения

С точки зрения производительности они точно такие же (по крайней мере, в SQL Server).

PS: имейте в виду, что синтаксис IMPLICIT OUTER JOIN устарел с SQL Server 2005. (Синтаксис IMPLICIT INNER JOIN, используемый в вопросе, все еще поддерживается)

Прекращение поддержки синтаксиса JOIN в "старом стиле": только отчасти

Лично я предпочитаю синтаксис соединения, поскольку он делает более ясным, что таблицы соединяются и как они соединяются. Попробуйте сравнить более крупные SQL-запросы, в которых вы выбираете из 8 разных таблиц, и у вас много фильтрации в where. Используя синтаксис соединения, вы отделяете части, в которых соединяются таблицы, от части, в которой вы фильтруете строки.

Performance wise, they are exactly the same (at least in SQL Server) but be aware that they are deprecating this join syntax and it's not supported by sql server2005 out of the box.

Я думаю, вы думаете об устаревших операторах * = и = * против «внешнего соединения».

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

В некоторых базах данных (особенно в Oracle) порядок объединений может иметь огромное значение для производительности запросов (если существует более двух таблиц). В одном приложении в некоторых случаях разница была буквально на два порядка. Использование синтаксиса внутреннего соединения дает вам контроль над этим - если вы используете правильный синтаксис подсказок.

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

@lomaxx: Чтобы уточнить, я почти уверен, что оба приведенных выше синтаксиса поддерживаются SQL Serv 2005. Однако приведенный ниже синтаксис НЕ поддерживается

select a.*, b.*  
from table a, table b  
where a.id *= b.id;

В частности, внешнее соединение (* =) не поддерживается.

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

Я согласен с grom, что вы должны использовать синтаксис соединения ANSI. По их словам, основная причина - ясность. Вместо того, чтобы иметь предложение where с множеством предикатов, некоторые из которых объединяют таблицы, а другие ограничивают строки, возвращаемые с синтаксисом соединения ANSI, вы делаете его ослепительно ясным, какие условия используются для объединения ваших таблиц, а какие используются для ограничения полученные результаты.

Как заявил Ли Колдуэлл, оптимизатор запросов может создавать разные планы запросов на основе того, что функционально выглядит как один и тот же оператор SQL. Для дальнейшего чтения ознакомьтесь с двумя следующими сообщениями в блогах: -

Одно сообщение от команды Oracle Optimizer

Еще одна запись из блога "Структурированные данные"

Надеюсь, вам это интересно.

Второй синтаксис имеет нежелательную возможность перекрестного соединения: вы можете добавлять таблицы в часть FROM без соответствующего предложения WHERE. Это считается вредным.

С точки зрения производительности это не должно иметь никакого значения. Синтаксис явного соединения кажется мне более понятным, поскольку он четко определяет отношения между таблицами в предложении from и не загромождает предложение where.

В MySQL 5.1.51 оба запроса имеют одинаковые планы выполнения:

mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)

mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)

table1 имеет 166208 строк; table2 имеет около 1000 строк.

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

По моему опыту, использование синтаксиса cross-join-with-a-where-clause часто приводит к нарушению плана выполнения, особенно если вы используете продукт Microsoft SQL. Например, способ, которым SQL Server пытается оценить количество строк в таблице, ужасен. Использование синтаксиса внутреннего соединения дает вам некоторый контроль над выполнением запроса. Итак, с практической точки зрения, учитывая атавистический характер современной технологии баз данных, вы должны использовать внутреннее соединение.

По сути, разница между ними в том, что один написан по-старому, а другой по-современному. Лично я предпочитаю современный сценарий, в котором используются определения internal, left, external, right, потому что они более понятны и делают код более читабельным.

При работе с внутренними соединениями нет никакой реальной разницы в удобочитаемости, однако это может усложниться при работе с левыми и правыми соединениями, поскольку в более старом методе вы получите что-то вроде этого:

SELECT * 
FROM table a, table b
WHERE a.id = b.id (+);

Вышеупомянутое - это старый способ записи левого соединения, в отличие от следующего:

SELECT * 
FROM table a 
LEFT JOIN table b ON a.id = b.id;

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

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