Запросы, которые не могут сделать неявные соединения SQL?

Да. При выполнении внешних соединений. Вы можете прочитать эту простую статью о соединениях. Соединения совсем не сложны для понимания, поэтому вы должны начать учиться (и использовать их там, где это уместно) прямо сейчас.

Всякий раз, когда вы захотите объединить результаты двух таблиц, вам нужно будет к ним присоединиться. Возьмем, к примеру:

Users table:

ID
FirstName
LastName
UserName
Password

and Addresses table:

ID
UserID
AddressType (residential, business, shipping, billing, etc)
Line1
Line2
City
State
Zip

where a single user could have his home AND his business address listed (or a shipping AND a billing address), or no address at all. Использование простого пункта Где не приведет к пользователю без адресов, так как адреса находятся в другой таблице. Для того, чтобы получить адреса пользователя сейчас, вам нужно сделать объединение как:

SELECT *
FROM Users
LEFT OUTER JOIN Addresses
    ON Users.ID = Addresses.UserID
WHERE Users.UserName = "foo"

Смотрите http://www.w3schools.com/Sql/sql_join.asp для более глубокого определения различных объединений и их работы.

Есть ли случаи, когда я не могу получить нужные результаты с помощью пункта WHERE и мне приходится использовать JOIN?

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

Если критерий соединения находится в пункте ГДЕ , то используется синтаксис ANSI-89 JOIN. Причина нового синтаксиса JOIN в формате ANSI-92 заключается в том, что он сделал LEFT JOIN более согласованным для различных баз данных. Например, Oracle использовал (+) на стороне, которая была необязательной, в то время как в SQL сервере нужно было использовать =*.

Используя Joins :

SELECT a.MainID, b.SubValue AS SubValue1, b.SubDesc AS SubDesc1, c.SubValue AS SubValue2, c.SubDesc AS SubDesc2
FROM MainTable AS a
LEFT JOIN SubValues AS b ON a.MainID = b.MainID AND b.SubTypeID = 1
LEFT JOIN SubValues AS c ON a.MainID = c.MainID AND b.SubTypeID = 2

Off-hand, я не вижу способа получить такие же результаты, используя простое выражение WHERE для присоединения к таблицам. Кроме того, синтаксис, обычно используемый в выражениях WHERE для левого и правого присоединения (*= и =*), постепенно исчезает,

Неявный синтаксис соединения по умолчанию использует Внутренние соединения. Иногда можно изменить синтаксис неявного соединения, чтобы указать внешние соединения, но по моему опыту это зависит от поставщика (я знаю, что у оракула есть нотация (-) и (+), и я считаю, что sqlserver использует *= ). Таким образом, я считаю, что ваш вопрос можно свести к пониманию различий между внутренними и внешними соединениями.

Мы можем посмотреть на простой пример внутреннего и внешнего соединения, используя простой запрос...........

Неявный INNER join:

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

Вышеприведенный запрос вернет ТОЛЬКО строки, в которых строка 'a' имеет соответствующую строку в 'b' для поля 'id'.

Явный запрос ВЧЕГО СОЕДИНЕНИЯ:

select * from
table a LEFT OUTER JOIN table b
on a.id = b.id;

Вышеприведенный запрос вернет КАЖДЫЙ ряд в 'a', независимо от того, имеет ли он совпадающую строку в 'b' или нет. Если для 'b' нет соответствия, поля 'b' будут нулевыми.

В этом случае, если вы хотите вернуть ОЧЕНЬ КАКОВЫЙ ряд в 'a', независимо от того, есть ли у него соответствующий 'b' ряд, вам нужно будет использовать внешнее соединение.

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

Неявные соединения устарели более чем на 20 лет. Зачем вам вообще думать о написании кода с их помощью?

Да, они могут создавать проблемы, которых нет у явных объединений. Говоря о SQL Server, неявный синтаксис левого и правого соединения не гарантирует возврата правильных результатов. Иногда они возвращают перекрестное соединение вместо внешнего соединения. Это плохо. Это было верно даже для SQL Server 2000, по крайней мере, они постепенно выводятся из употребления, поэтому их использование - плохая практика.

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

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

Я считаю, что некоторые ORM теперь также требуют явных соединений.

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

Если вы пишете код SQL любого типа, нет оправдания непониманию соединений.