Есть ли что-то не так с соединениями, которые не используют ключевое слово СОЕДИНЕНИЯ в SQL или MySQL?

Более подробным INNER JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN, FULL OUTER JOIN является от ANSI SQL/92 синтаксис для присоединения. Для меня это многословие делает соединение более ясным разработчику/DBA того, что намерение с соединением.

В SQL Server всегда существуют планы запросов для проверки, текстовый вывод может быть сделан следующим образом:

SET SHOWPLAN_ALL ON
GO

DECLARE @TABLE_A TABLE
(
    ID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
    Data VARCHAR(10) NOT NULL
)
INSERT INTO @TABLE_A
SELECT 'ABC' UNION 
SELECT 'DEF' UNION
SELECT 'GHI' UNION
SELECT 'JKL' 

DECLARE @TABLE_B TABLE
(
    ID INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
    Data VARCHAR(10) NOT NULL
)
INSERT INTO @TABLE_B
SELECT 'ABC' UNION 
SELECT 'DEF' UNION
SELECT 'GHI' UNION
SELECT 'JKL' 

SELECT A.Data, B.Data
FROM
    @TABLE_A AS A, @TABLE_B AS B
WHERE
    A.ID = B.ID

SELECT A.Data, B.Data
FROM
    @TABLE_A AS A
    INNER JOIN @TABLE_B AS B ON A.ID = B.ID

Теперь я опущу план относительно табличной переменной, создает, план относительно обоих запросов идентичен хотя:

 SELECT A.Data, B.Data  FROM   @TABLE_A AS A, @TABLE_B AS B  WHERE   A.ID = B.ID
  |--Nested Loops(Inner Join, OUTER REFERENCES:([A].[ID]))
       |--Clustered Index Scan(OBJECT:(@TABLE_A AS [A]))
       |--Clustered Index Seek(OBJECT:(@TABLE_B AS [B]), SEEK:([B].[ID]=@TABLE_A.[ID] as [A].[ID]) ORDERED FORWARD)
 SELECT A.Data, B.Data  FROM   @TABLE_A AS A   INNER JOIN @TABLE_B AS B ON A.ID = B.ID
  |--Nested Loops(Inner Join, OUTER REFERENCES:([A].[ID]))
       |--Clustered Index Scan(OBJECT:(@TABLE_A AS [A]))
       |--Clustered Index Seek(OBJECT:(@TABLE_B AS [B]), SEEK:([B].[ID]=@TABLE_A.[ID] as [A].[ID]) ORDERED FORWARD)

Так, короткий ответ - Никакая потребность переписать, если Вы не проводите долгое время, пытаясь считать их каждый раз, Вы поддерживаете их?

Это - больше выбора синтаксиса. Я предпочитаю группировать свои условия объединения с моими соединениями, следовательно я использую синтаксис ВНУТРЕННЕГО ОБЪЕДИНЕНИЯ

SELECT a.someRow, b.someRow
FROM tableA AS a
INNER JOIN tableB AS b
  ON a.ID = b.ID
WHERE b.ID = ?

(? будучи заполнителем)

Ничто не неправильно с синтаксисом в Вашем примере. Синтаксис 'ВНУТРЕННЕГО ОБЪЕДИНЕНИЯ' обычно называют синтаксисом 'ANSI' и прибыл после того, как стиль проиллюстрировал в Вашем примере. Это существует для разъяснения типа/направления/составляющих соединения, но обычно функционально не отличается, чем, что Вы имеете.

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

Как примечание стороны, одно дополнение с синтаксисом 'ANSI' было 'ПОЛНЫМ ВНЕШНИМ ОБЪЕДИНЕНИЕМ' или 'ПОЛНЫМ СОЕДИНЕНИЕМ'.

Hope это помогает.

В целом:

Использование ключевое слово СОЕДИНЕНИЯ для соединения (т.е. "соединение") первичных ключей и внешних ключей.

Использование оператор Where для ограничения набора результатов только записями Вы интересуетесь.

Одна проблема, которая может возникнуть, состоит в том, когда Вы пытаетесь смешаться, старое соединение "стиля запятой" с SQL-92 участвует в том же запросе, например, при необходимости в одном внутреннем объединении и другом внешнем объединении.

SELECT *
FROM table1 AS a, table2 AS b
 LEFT OUTER JOIN table3 AS c ON a.column1 = c.column1
WHERE a.column2 = b.column2;

проблема состоит в том, что в недавних стандартах SQL говорится, что СОЕДИНЕНИЕ оценено перед соединением запятой. Таким образом, ссылка на "a" в НА пункте дает ошибку, потому что имя корреляции еще не было определено как, который НА пункте оценивается. Это - очень запутывающая ошибка добраться.

решение не состоит в том, чтобы смешать два стиля соединений. Можно продолжить использовать стиль запятой в старом коде, но если Вы пишете новый запрос, преобразовываете все соединения в стиль SQL-92.

SELECT *
FROM table1 AS a
 INNER JOIN table2 AS b ON a.column2 = b.column2
 LEFT OUTER JOIN table3 AS c ON a.column1 = c.column1;

Другая вещь рассмотреть в старом синтаксисе соединения, это, очень легко получить соединение cartesion случайно, так как существует не на пункте. Если Отличное ключевое слово находится в запросе, и это использует старые соединения стиля, преобразуйте, это к стандарту ANSI присоединяется и видит, нужно ли Вам все еще отличное. При фиксации случайных соединений cartesion этот путь можно улучшить производительность чрезвычайно путем перезаписи для определения соединения и объединяющих полей.

Я избегаю неявных соединений; когда запрос является действительно большим, они делают код трудно для дешифровки

С явными соединениями и хорошим форматированием, код более читаем и понятен без потребности в комментариях.

Это также зависит от того, делаете ли Вы просто внутренние объединения этот путь или внешние объединения также. Например, синтаксис SQL Server MS для внешних объединений в операторе Where (= * и * =) может дать различные результаты, чем синтаксис ВНЕШНЕГО ОБЪЕДИНЕНИЯ и больше не поддерживается ( http://msdn.microsoft.com/en-us/library/ms178653 (SQL.90) .aspx) в SQL Server 2005.